@rizom/ops 0.2.0-alpha.483 → 0.2.0-alpha.484

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -4,11 +4,11 @@ Operator CLI package for managing pilot brain fleet registry repos.
4
4
 
5
5
  ## Runtime images
6
6
 
7
- The fleet builds one immutable `brain-${brainVersion}` image per effective Brain version. Every new image includes the union of exact site and theme package pins across the entire fleet, including users still running older Brain versions. Smoke-to-fleet promotion therefore reuses the same image without changing package pins or publishing another Brain release. Conflicting pins fail before build, even across cohorts on different Brain versions.
7
+ The fleet builds one immutable image per effective Brain version and site pin set. An instance without a site override runs `brain-${brainVersion}`; an instance with one runs `brain-${brainVersion}--<pins>`, the pins spelled out and sorted (`@rizom/site-x@1.2.3` → `rizom-site-x-1.2.3`), or a digest of them when spelling them out would exceed a registry's tag length. Every instance with the same version and pins shares one image. A site's pin change therefore builds that site's image and no other, and smoke-to-fleet promotion reuses the smoke-tested image unchanged, because its name already carries its pins. The generated `users/<handle>/.env` of an instance with site pins names its image (`IMAGE_TAG`), so a pin change is a changed config and deploys; a plain instance's env says only its version.
8
8
 
9
- Before reusing an existing image, Build verifies its actual installed Brain and package versions against its current adopters. Deploy independently verifies the selected instance's requirements before provisioning or replacing containers, including manual deploys. Verification runs only a manifest-reading command in a read-only, network-disabled container on the CI runner; it never starts the Brain or mounts fleet data. Missing packages, mismatched versions, and verification failures stop the workflow. Existing images are not required to serve cohorts that have not adopted them yet.
9
+ Before reusing an existing image, Build verifies its actual installed Brain and package versions against what its name says it holds. Deploy independently verifies the selected instance's requirements before provisioning or replacing containers, including manual deploys. Verification runs only a manifest-reading command in a read-only, network-disabled container on the CI runner; it never starts the Brain or mounts fleet data. Missing packages, mismatched versions, and verification failures stop the workflow.
10
10
 
11
- Explicit builds also load the fleet registry and include its complete package union; `site_packages` adds extra exact pins rather than replacing the union. Package-set changes after an image was published may make that immutable image unsuitable: the gates reject reuse rather than silently rebuilding it. Recovery of an already deployed incomplete image requires a separately reviewed artifact recovery plan.
11
+ Explicit builds (`brain_version` and `site_packages` dispatch inputs) build exactly the dispatched version and pins. Published tags are immutable: the gates reject reuse of an image that does not hold what its name says rather than silently rebuilding it. Recovery of an already deployed incomplete image requires a separately reviewed artifact recovery plan.
12
12
 
13
13
  ## Commands
14
14