@xemahq/xema 0.18.0 → 0.18.1

package/README.md

@@ -111,8 +111,35 @@ the container substrate, from the owned release's Deployment
 at the foreground `xema up` / `xema dev` console (that is where native
 services log).
 
-The launcher and automation use the same compiled desired state. The
-installation command group exposes that lifecycle directly:
+The launcher and automation use the same compiled desired state — one
+`XemaInstallation` document — and the target kind decides who executes it.
+
+### Installing on Kubernetes — the boring path
+
+```bash
+npm i -g @xemahq/deployment-engine                      # the ONE deployment engine
+xema installation init --profile single-node-production \
+  --target customer-kubernetes --context <kubectl-context> --kubeconfig ./kubeconfig \
+  --name acme-prod --edition oss
+#   …fill in xema.installation.yaml: namespace, domains, external infrastructure…
+xema installation validate --file xema.installation.yaml   # providers, then the deployment root
+xema installation plan     --file xema.installation.yaml   # what apply would change
+xema installation apply    --file xema.installation.yaml   # reconcile, wave by wave
+xema installation verify   --file xema.installation.yaml   # every release present and converged
+```
+
+On a `customer-kubernetes` or `single-node-kubernetes` target every verb
+PROJECTS the installation into a deployment root — `deployment.yaml`,
+`infra.yaml`, `secret-inputs.yaml`, `values.yaml` and the edition's two lock
+files, under `~/.xema/installations/<name>/deployment/` or beside the
+installation file when that directory already holds a `deployment.yaml` —
+and runs `xema-deployment-engine` over it. The CLI never renders a chart,
+ranks a wave or reads a lock; the engine does, and it is resolved from
+`XEMA_DEPLOYMENT_ENGINE` (a bin or a package root) or the installed
+`@xemahq/deployment-engine`. A declaration the root cannot carry is refused by
+name rather than dropped, and nothing in the root is ever a secret value.
+
+### Installing on this machine
 
 ```bash
 xema installation plan                    # deterministic redacted change plan
@@ -122,8 +149,9 @@ xema installation support-bundle          # redacted JSON + SHA-256 integrity ma
 ```
 
 Destructive transitions are refused unless explicitly reviewed and authorized
-with `--allow-destructive`; rejected identity/schema transitions and currently
-unsupported profiles remain fail-fast. Last-applied state is atomically stored
+with `--allow-destructive`; rejected identity/schema transitions and the
+profiles without a renderer (`business-ha`, `enterprise-regulated`,
+`hosted-cell`) remain fail-fast. Last-applied state is atomically stored
 under `~/.xema/installations/<installation-id>/`, while secret values are
 resolved before source or deployment side effects and are never persisted in
 plans or support bundles.