Chapter 10 of 11 · 2 min read
Release Engineering and Compatibility
Immutable packages, exact dependency pins, protected build credentials, and predictable deployment.
The ~WellbeingIdentity Rendering Architecture · v0.2 · edition history · Moses Sam Paul
Quick Answer
The shared contracts and renderer are immutable restricted package releases. Consumers use exact versions and committed lockfiles. A protected project credential permits the deployment environment to install them; it is never committed, displayed, or carried by the renderer.
Visual consistency is an operational property as well as a design property. If a consumer resolves a different renderer at build time, a carefully tested interaction contract can quietly change in production. Exact package versions make the intended behaviour inspectable.
Type, interaction, privacy-boundary, and responsive checks run in the relevant product.
Contracts `0.1.4`; renderer `0.2.2`.
Lockfile resolves the intended artifact.
A project credential enables restricted dependency retrieval.
The product build publishes its own reviewed surface.
The authentication incident
The deployment environment initially could not retrieve the restricted renderer package. The build did not fail because the code was missing; it failed because no protected package credential had been configured for that project. The remedy was to configure a project-scoped build secret with the minimum package permission. It was not to make the package public, place a token in a repository, or make a renderer fetch its own dependencies.
Compatibility is intentional
The release ledger records contracts 0.1.4 and renderer 0.2.2 as immutable artifacts. Value Log and Foundation use exact consumer versions; Explorer does not consume the renderer. Clean installs, lockfile resolution, package tests, product tests, and production builds are all part of the compatibility claim. A package version by itself is not proof; reproducible installation and a passing consumer build complete the chain.