Pins and the release manifest
The MyceliumMyceliumThe application infrastructure underneath NovusLens. Its connected services exchange updates and keep the ordered structural log. pinPinA recorded choice of one exact dependency version. It prevents an update from changing that dependency without a deliberate decision. fixes the storage software used by NovusLens. The release manifestRelease manifestThe file recording the exact software versions and fingerprints used for a NovusLens release candidate. Installation checks compare files against it. records SDKSDKSoftware development kit: a package of code that helps another program use a service. NovusLens uses mycelium-py to talk to Mycelium. and sidecarSidecarA separate supporting process that runs beside the application. Here it runs Mycelium and exposes the gateway that NovusLens calls. builds, platform hashesHashA fixed-length fingerprint calculated from content. Comparing fingerprints helps detect changes and match records. and verification limits. Container imagesContainer imageA packaged application and the software it needs. Docker starts a container from this package. carry their own code and dependencies. No host Mycelium checkout, Rust compiler or Python installation is required.
Container selection
Every public command runs the release the installation records. --version overrides it for one run, within the same mode. Without a record, the default is latest.
| Selection | Code used |
|---|---|
dev | Local source bound into containersContainerA running program with its own packaged software and isolated environment, managed by Docker on the host.. |
local | Frozen images built from local source. |
latest | The current images published by the latest successful main push. |
nightly | The images published by the latest successful nightly rehearsal of main. |
0.x.y | One immutable published release. |
Use --version dev for checks against an edited checkout. An installation does not need the version repeated: later commands read it from .novuslens.env.
The Docker architecture explains image selection and persistent storage.
Build identities
config/mycelium.pin contains the full Git identifier for the selected Mycelium tag.
The shared base build fetches that object, checks its identity and applies deploy/sidecar/gateway.patch.
It then builds the Linux sidecar with the pinned Rust toolchain.
The base contains the operating system, core utilities and compiled Mycelium binaryBinaryA program file built to run on a particular kind of machine. A program built for one processor may not run on another..
The five application images and ops controller inherit it. Unchanged base inputs reuse the built image.
./lens ops --version dev sidecar copies the image’s binary into the checkout’s .sidecar/ directory.
It does not compile a host checkout.
The manifest records the SDK wheelWheelA packaged Python library ready to install. A vendored wheel is stored in this repository so its exact bytes can be checked.’s package name, version and SHA-256SHA-256A method that turns content into a fixed-length fingerprint. Comparing fingerprints helps check whether content changed. hashHashA fixed-length fingerprint calculated from content. Comparing fingerprints helps detect changes and match records.. It also records sidecar hashes for named operating systems and machine types. A Darwin hash describes the retained Darwin build. It cannot establish the identity of a Linux binary. Each platform’s status states the checks recorded for that build.
The manifest’s historical candidate label does not establish that current containers passed their checks. Use the matching CIContinuous integrationAutomated checks run when code changes, usually including building the code and running tests. results and acceptance evidence for that conclusion.
What each check covers
| Check | What it checks | Failure behaviour |
|---|---|---|
| Shared Mycelium base build | Fetched object matches the pin; gatewayGatewayA service that accepts requests and passes them into another system. The Mycelium gateway gives NovusLens access to the mesh. patch applies. | The build stops. |
deploy/docker/verify_sdk.py | Wheel hash, package name and version match the manifest. | The Python image build or source bundle stops. |
deploy/bundle.sh | The committed source archive can be extracted safely and contains the recorded SDK wheel. | The bundle is refused. |
./lens doctor and deployment | All running sidecar identities, the SDK wheel and version, customer configuration and database readiness. | Doctor reports the repair; deployment stops before reporting the installation ready. |
Ops pin_check | The sidecar’s hash matches the manifest entry for its platform. | A mismatch is reported as an unrecorded build. |
| Customer-profile acceptance gates | The platform has the expected sidecar hash before boundary or durability checks run. | The gate stops. |
| Container publication | Source and revision labels, both machine types and the complete tested image set. | Publication is refused on an identity or release conflict. |
A portable source bundle contains no host sidecar binary. It does not compare a host binary with the manifest. Published image identities and the source archive’s SDK checks cover different boundaries.
For a source bundle from the development checkout:
./lens ops --version dev exec -- deploy/bundle.sh --version devCommit intended source changes first. The bundle archives the selected runner’s committed source, excluding uncommitted edits. Frozen modes archive the code packaged in their selected image.
Publishing and retaining images
Every main push builds the shared base and five application images for Linux amd64 and arm64, runs the quick Python and UI checks, and publishes them as latest without a rehearsal.
Nightly and published release runs build and rehearse all six images.
Successful nightlies publish them as nightly and move the Git tag nightly.
Published releases use immutable 0.x.y tags, accepting an optional v prefix, and leave latest unchanged.
Cleanup removes obsolete rolling images only when no protected release, current image or other retained object references them.
Pull requests run fast Docker and installer checks without the full build and rehearsal matrix.
The installer uses the Compose definition packaged in a published image.
A development source overlay is used only for dev.
See Docker deployment for installation commands.
Changing the Mycelium pin
A re-pin is a deliberate dependency change, followed by new build and acceptance evidence.
- Select the upstream tag and review its storage behaviour, reserved key prefixes and SDK versions.
- Update
config/mycelium.pin. Rebuild the SDK wheel from that tag in a container and update its lockfile record. - Rebuild the shared Mycelium base. If the gateway patch fails, update the patch before continuing.
- Record the new wheel metadata and each built platform’s sidecar hash in the manifest.
- Run the relevant customer checks and acceptance gates. Record their actual results and remaining limits.
- Update
config/pins.mdand the current wiki pages before preparing a source bundle or published release.
Changing the sidecar’s operating system or machine type can require another platform hash without changing the upstream pin. A recorded hash is not a substitute for running the acceptance gates.
Dependency audit
The test gate audits production Node dependencies and the locked Python dependency set.
config/audit-triage.json records accepted advisories with a status and reason.
A missing or incomplete report fails the audit, as does an untriaged advisory.
The Python audit excludes the vendored Mycelium SDK; the wheel’s identity is checked separately.