diff --git a/marketplace b/marketplace
index af08be90..42b87895 160000
--- a/marketplace
+++ b/marketplace
@@ -1 +1 @@
-Subproject commit af08be9003881112a9f16cc991a1379a9df0bd20
+Subproject commit 42b8789543f8ed06b7cac099284eb3871c582efc
diff --git a/src/content/docs/recipes/core/charly-doctor.md b/src/content/docs/recipes/core/charly-doctor.md
index 3a0eff25..f9cf92fb 100644
--- a/src/content/docs/recipes/core/charly-doctor.md
+++ b/src/content/docs/recipes/core/charly-doctor.md
@@ -130,7 +130,7 @@ Each check shows the binary path and version when available, or an install hint
 ## Cross-References
 
 - [`/charly-automation:udev`](/recipes/automation/udev/) — install udev rules for GPU device access
-- [`/charly-core:charly-config`](/recipes/core/charly-config/) — `engine.build`, `engine.run`, `secret_backend` settings, `--no-auto-detect` flag, DRINODE injection via `appendAutoDetectedEnv()`
+- [`/charly-core:charly-config`](/recipes/core/charly-config/) — `engine.run`, `secret_backend` settings, `--no-auto-detect` flag, DRINODE injection via `appendAutoDetectedEnv()`
 - [`/charly-automation:enc`](/recipes/automation/enc/) — credential lookup path behind the Secret Service collection + keyring-index checks; iteration-capable ssClient; broken-collection troubleshooting
 - [`/charly-build:secrets`](/recipes/build/secrets/) — `charly secrets set/list/prune` commands referenced by the keyring-index remediation hint
 - [`/charly-build:settings`](/recipes/build/settings/) — `keyring_collection_label`, `secret_backend`, and other runtime config keys surfaced by the Secret Storage checks
diff --git a/src/content/docs/recipes/core/charly-status.md b/src/content/docs/recipes/core/charly-status.md
index ccc0af3a..282fb12a 100644
--- a/src/content/docs/recipes/core/charly-status.md
+++ b/src/content/docs/recipes/core/charly-status.md
@@ -69,10 +69,10 @@ former `status-substrate` HostBuild seam is DELETED, K-wave 2).
 - `candy/plugin-status/nested_tree.go` — the declared-nested-tree pre-resolution
   (K5, relocated from charly/status_nested.go's buildStatusRootsTree): resolves
   the merged project + per-machine deploy tree directly (`HostBuild("resolved-
-  project")` + `deploykit.LoadFleetConfig`) into the wire-safe
+  project")` + `deploykit.LoadDeployConfig`) into the wire-safe
   `[]spec.StatusNestedNode` shape the overlay folds, including the `--nested`
   live-probe leg (`ResolveDeployChain` + `NestedExecutor`, the SAME primitive
-  `charly fleet add` / `charly check live parent.child` use).
+  `charly deploy add` / `charly check live parent.child` use).
 - `candy/plugin-status/command.go` (`hostStatusSubstrate`) — the generic
   `status-substrate` F10 forward is DELETED with `charly/status_substrate_host.go`
   (K-wave 2): `command:status` now `InvokeProvider(verb:status-fanout)` DIRECTLY over
@@ -200,7 +200,7 @@ match keeps the synthesized declared row (`Source="nested"`).
   subprocesses.
 - **`charly status --nested`**: each child's LIVE venue is probed through the real
   multi-hop chain (`ResolveDeployChain` → `NestedExecutor`, the SAME primitive
-  `charly fleet add` and `charly check live parent.child` use — no bespoke nested dial)
+  `charly deploy add` and `charly check live parent.child` use — no bespoke nested dial)
   under a STRICT 4-second per-child context deadline. A timed-out / failing
   child renders `unreachable`; the table is NEVER blocked. The deadline is a
   context cancellation, never a sleep/retry loop. `--nested` also turns on live
@@ -318,7 +318,7 @@ Authoritative direct queries (when you need the raw mount data):
 
 ```bash
 charly status <image> --json    # volumes[] carries the live mounts
-charly fleet show <image>
+charly deploy show <image>
 ```
 
 ## Usage
diff --git a/src/content/docs/recipes/core/clean.md b/src/content/docs/recipes/core/clean.md
index c9e08c9e..498bb491 100644
--- a/src/content/docs/recipes/core/clean.md
+++ b/src/content/docs/recipes/core/clean.md
@@ -1,6 +1,6 @@
 ---
 title: "clean"
-description: "Prune reusable build artifacts to defaults: retention (images, check runs) and sweep one-time makepkg leftovers — `charly clean`, keep_images/keep_check_runs, image-tag pruning, .check run cleanup."
+description: "Prune reusable build artifacts to defaults: retention (images, check runs) and sweep one-time build-candy leftovers — `charly clean`, keep_images/keep_check_runs, image-tag pruning, .check run cleanup."
 ---
 
 <!-- DO-NOT-EDIT — generated by `charly docs generate`; the opencharly/docs repo's deploy workflow regenerates this tree against its pinned charly checkout. -->
@@ -39,7 +39,7 @@ opts in; third-party configs get no surprise pruning until they set a value.
 ## Commands
 
 ```bash
-charly clean              # apply retention now: prune images + check runs + makepkg leftovers
+charly clean              # apply retention now: prune images + check runs + build-candy leftovers
 charly clean --dry-run    # print everything that WOULD be removed; touch nothing
 charly clean --images     # only image-tag retention
 charly clean --check       # only check-run retention
@@ -50,12 +50,28 @@ charly clean --deep --dry-run   # the safe default probe: report the would-remov
 charly clean --keep N     # override the retention count for this run (0 = use defaults:)
 charly clean --invalidate '<glob>'   # remove charly-labeled image tags matching the glob
                                      # (full ref or last segment; in-use skipped; runs ONLY this)
+charly clean --cache      # reclaim unreferenced blobs from every named charly cache (the
+                          # content-addressed ArtifactStore's own GC); reports each store's live
+                          # entries + the blobs/bytes it would reclaim; runs ONLY this category
+charly clean --scopes     # reap HUNG transient build scopes — the systemd user scopes
+                          # buildah/podman put a build container into (runc-buildah-*.scope).
+                          # A scope is stopped only when it has hung; a live one is left alone
 ```
 
-With neither `--images` nor `--check` nor `--deep`, the three DEFAULT categories run (images +
-check + makepkg) — unchanged, `--deep` NEVER fires implicitly. `--keep N` overrides both the
-image and check-run retention counts for the invocation (it does not affect `--deep`, which has
-no keep-N — it purges every untagged image).
+With **none** of `--images` / `--check` / `--deep` / `--cache` / `--scopes`, the **four** DEFAULT categories
+run (image-tag + check-run + build-candy + scopes) — unchanged, and `--deep` and `--cache` NEVER fire
+implicitly. `--scopes` IS in that list because it is itself a category flag: the test the code applies is
+`anyCategory := images || check || deep || cacheGC || scopes`, so naming ANY one of the five suppresses the
+default set and runs only what was named (plus, for `--deep`, the scope reap below).
+**`--scopes` is a default and `--deep` implies it:** `cleanCategories` computes
+`doScopes = scopes || deep || !anyCategory`, so a bare `charly clean` reaps hung build scopes
+and `--deep` does too, while `--deep` on its own runs only the image half plus that scope reap — and
+`--cache` on its own runs only the cache sweep, with `doScopes` false.
+`--keep N` overrides both the image and check-run retention counts for the invocation (it does
+not affect `--deep`, which has no keep-N — it purges every untagged image).
+**Category names, from the engine's own header** (`retention.go`): *image-tag / build-candy / check-run
+pruning*, plus the `--deep` store-wide purge and the `--cache` blob sweep. The middle one prunes
+`.build/_candy/<candy>.<version>/` per candy (`pruneBuildCandyDirs`).
 
 **`--deep` — the store-wide untagged/dangling-image purge.** The default image-tag sweep above
 only ever touches images carrying the `ai.opencharly.box` label. A multi-stage build's
@@ -195,7 +211,7 @@ importing only `sdk/kit` + `spec/spec`). `--deep` shares its engine with the def
 charly-labeled dangling sweep via `pruneDanglingImages`/`selectDanglingImages`
 (`candy/plugin-clean/retention.go`) parameterized by an `onlyCharly` bool: `pruneDanglingCharlyImages`
 (onlyCharly=true, the default sweep) and `pruneDeepDanglingImages` (onlyCharly=false, `--deep`)
-are both thin wrappers over the ONE shared selection + removal engine (R3 — no duplicated
+are both thin wrappers over the ONE shared selection + removal engine (R2 — no duplicated
 listing/removal logic between the two categories). The engine is reached two ways: `charly
 clean`'s own CLI calls `runRetention` in-package (no wire hop); the three OTHER callers reach
 `verb:retention` — the build command's post-build prune (`candy/plugin-box/box.go`'s
diff --git a/src/content/docs/recipes/core/deploy.md b/src/content/docs/recipes/core/deploy.md
index 8c19e8c6..021147bb 100644
--- a/src/content/docs/recipes/core/deploy.md
+++ b/src/content/docs/recipes/core/deploy.md
@@ -1,6 +1,6 @@
 ---
 title: "deploy"
-description: "`charly fleet add`/`charly fleet del`, quadlet generation, volume backing, tunnels (Tailscale/Cloudflare), `add_candy:` overlay, or per-machine deploy overlays."
+description: "`charly deploy add`/`charly deploy del`, quadlet generation, volume backing, tunnels (Tailscale/Cloudflare), `add_candy:` overlay, or per-machine deploy overlays."
 ---
 
 <!-- DO-NOT-EDIT — generated by `charly docs generate`; the opencharly/docs repo's deploy workflow regenerates this tree against its pinned charly checkout. -->
@@ -15,26 +15,26 @@ description: "`charly fleet add`/`charly fleet del`, quadlet generation, volume
 - **The substrate node at the edge** — `vm: {from: <entity>}` for a VM target, `pod: {image: <name>}` for a pod target, `kubernetes: {from: <name>}` for a cluster target, `local: {from: <template>}` for a local-deploy. Deploy-into nesting is **tree position** (a resource node placed under another resource), not a `nested:` field; sibling members (a resource node placed under the deploy) replace the old `peer:` field.
 - **`host:` is a FIELD on `local:`, never a deploy KIND (MUST).** A host/remote deploy MUST be authored as `local: {from: <template>, host: <user@machine>}` — the `host:` scalar on a `local:` (or `pod:`) deploy: `host: local` / absent = this machine, `host: <user@machine>` = SSH. There is NO standalone `host:` venue KIND; authoring a `host:` node is a hard load error. See [`/charly-local:local-deploy`](/recipes/local/local-deploy/).
 - **`group:` is EXCLUSIVELY a targetless deploy group.** A `group:` node carries only resource members (pod/vm/etc.) with no own workload — the targetless deploy group.
-- **Disposability is a deploy property** — `FleetNode.Disposable` (the `disposable:` scalar under the substrate node) is the sole source of truth.
+- **Disposability is a deploy property** — `DeployNode.Disposable` (the `disposable:` scalar under the substrate node) is the sole source of truth.
 - **Resource arbitration is a deploy property** — the `preemptible:` field (holder; occupies exclusive host-resource token(s), may be gracefully stopped + restored), the `requires_exclusive:` field (claimant; needs SOLE use), and the `requires_shared:` field (claimant; REFCOUNTED shared use — many concurrent claimants; a GPU-token claim flips the whole IOMMU group vfio→nvidia+CDI at deploy, back at teardown when the LAST claimant releases) — all inline in the substrate node — drive the arbiter (`charly preempt`). A fourth axis ORTHOGONAL to disposable/ephemeral/lifecycle. See "Preemptible resource arbitration" below + [`/charly-internals:disposable`](/recipes/internals/disposable/).
 - **Disposable R10 test beds are just `disposable: true` deploys** (run via `charly check run <bed>`) — there is NO separate bed kind. The main repo's beds (`check-pod`, `check-k3s-vm`, `check-sway-browser-vnc-pod`, …) AND every `box/<distro>` submodule's beds (the arch / cachyos / debian / ubuntu / fedora bootstrap-VM + pacstrap/debootstrap beds, in each submodule's `charly.yml`) are disposable deploys. The cachyos submodule's `charly-cachyos` operator workstation profile is a non-disposable deploy (a profile, not a test bed). Operator deployments otherwise live in the per-host `~/.config/charly/charly.yml`. See [`/charly-check:check`](/recipes/check/check/) "disposable check deploys".
 
 ## Overview
 
-`charly fleet` is the parent verb for applying and tearing down deployments, plus managing `charly.yml` overrides. The command family has two distinct surfaces:
+`charly deploy` is the parent verb for applying and tearing down deployments, plus managing `charly.yml` overrides. The command family has two distinct surfaces:
 
-1. **Execution verbs** — `charly fleet add <name>` / `charly fleet del <name>`. Apply or reverse a deployment. The target is dispatched by which substrate node the deploy carries:
+1. **Execution verbs** — `charly deploy add <name>` / `charly deploy del <name>`. Apply or reverse a deployment. The target is dispatched by which substrate node the deploy carries:
    - `local: {from: <template>}` → the external `deploy:local` plugin (`candy/plugin-deploy-local`) applies to the local filesystem over the executor reverse channel (or, placed under another resource node via tree position, via NestedExecutor into the enclosing deployment). See [`/charly-local:local-deploy`](/recipes/local/local-deploy/).
    - `vm: {from: <entity>}` → the external `deploy:vm` plugin (`candy/plugin-deploy-vm`) applies INSIDE a running VM over SSH via the reverse channel; the plugin auto-boots the venue in its `OpPrepareVenue` (via `HostBuild("cli")`), using the host prepare hook's resolved data. See "VM target" section below and [`/charly-internals:vm-deploy-target`](/recipes/internals/vm-deploy-target/).
    - `pod: {image: <image>}` → the candy `plugin-deploy-pod` renders the overlay Containerfile (in its own code via `deploykit.OCITarget` + `deploykit.NewRenderGeneratorFromProject`) + the quadlet config-write (fully plugin-side in `candy/plugin-deploy-pod` + `sdk/deploykit/quadlet_paths.go` — the former core quadlet path is DELETED, K-wave 2).
    - `kubernetes: {from: <name>}` → Kustomize base/overlays tree. See [`/charly-kubernetes:kubernetes`](/recipes/kubernetes/kubernetes/).
-2. **Config-file management** — `charly fleet show/export/import/reset/path/status`. Read and mutate `~/.config/charly/charly.yml` itself.
+2. **Config-file management** — `charly deploy show/export/import/reset/path/status`. Read and mutate `~/.config/charly/charly.yml` itself.
 
 ## Targets, one schema
 
-The same `FleetNode` shape feeds every target (`pod`, `local`, `vm`, `kubernetes`, `android`) — authors describe *what the workload needs* (ports, volumes, env, security, tests); the generator per target decides *how Kubernetes / quadlet / local apply / VM over SSH / Android apk-install* realizes it.
+The same `DeployNode` shape feeds every target (`pod`, `local`, `vm`, `kubernetes`, `android`) — authors describe *what the workload needs* (ports, volumes, env, security, tests); the generator per target decides *how Kubernetes / quadlet / local apply / VM over SSH / Android apk-install* realizes it.
 
-A deploy's install timeline can include a `run:` step carrying a plugin verb (the `<word>: <input>` sugar — see [`/charly-image:layer`](/recipes/image/layer/) "Plugin verb steps"). When the verb is served by an EXTERNAL (out-of-process) plugin, that step EXECUTES at deploy on a `local:`/`vm:` target — the plugin runs its effect on the live venue over the executor reverse channel (`Invoke(OpExecute)`) and returns teardown `ReverseOp`s the target records to the ledger and replays at `charly fleet del`. A builtin `ProvisionActor` verb keeps its in-proc shell path; the two are placement-agnostic (same authored step, the runtime picks the path). Detail → [`/charly-internals:install-plan`](/recipes/internals/install-plan/) (the `ExternalPluginStep` IR kind) + [`/charly-internals:plugin`](/recipes/internals/plugin/).
+A deploy's install timeline can include a `run:` step carrying a plugin verb (the `<word>: <input>` sugar — see [`/charly-image:layer`](/recipes/image/layer/) "Plugin verb steps"). When the verb is served by an EXTERNAL (out-of-process) plugin, that step EXECUTES at deploy on a `local:`/`vm:` target — the plugin runs its effect on the live venue over the executor reverse channel (`Invoke(OpExecute)`) and returns teardown `ReverseOp`s the target records to the ledger and replays at `charly deploy del`. A builtin `ProvisionActor` verb keeps its in-proc shell path; the two are placement-agnostic (same authored step, the runtime picks the path). Detail → [`/charly-internals:install-plan`](/recipes/internals/install-plan/) (the `ExternalPluginStep` IR kind) + [`/charly-internals:plugin`](/recipes/internals/plugin/).
 
 **An `android:` deploy** installs a deploy's `add_candy:` candies' `apk:` packages
 onto an `android` device entity (an in-pod emulator or a remote/physical adb
@@ -45,36 +45,36 @@ a cluster. The substrate node is `android: {from: <device>}`; apps
 ride in on the deploy's inline `add_candy:` list (no apk-list field). A `pod → android` tree
 (the device placed under its emulator-pod node) mirrors `vm → kubernetes`; a pod's android
 children deploy AFTER `charly start` (use `--node-only` on the pod's deploy-add, then
-dotted-path `charly fleet add pod.device`). See [`/charly-check:android`](/recipes/check/android/). Kubernetes-specific choices (storage class, ingress class, cert issuer, secret backend) live in a **cluster profile** file (`~/.config/charly/clusters/<name>.yaml` or in-repo `clusters/<name>.yaml`), *not* in the deployment. This means one deployment spec targets dev/staging/prod clusters with zero schema changes — only the cluster profile differs.
+dotted-path `charly deploy add pod.device`). See [`/charly-check:android`](/recipes/check/android/). Kubernetes-specific choices (storage class, ingress class, cert issuer, secret backend) live in a **cluster profile** file (`~/.config/charly/clusters/<name>.yaml` or in-repo `clusters/<name>.yaml`), *not* in the deployment. This means one deployment spec targets dev/staging/prod clusters with zero schema changes — only the cluster profile differs.
 
-`charly start` / `charly stop` remain as ergonomic wrappers: `charly start <image>` is equivalent to `charly fleet add <image> <image>` with the container target; `charly stop <name>` is `charly fleet del <name>`. New scripts should prefer the explicit `charly fleet add`/`charly fleet del` forms, especially when using `--add-candy` overlays or the `host` target.
+`charly start` / `charly stop` remain as ergonomic wrappers: `charly start <image>` is equivalent to `charly deploy add <image> <image>` with the container target; `charly stop <name>` is `charly deploy del <name>`. New scripts should prefer the explicit `charly deploy add`/`charly deploy del` forms, especially when using `--add-candy` overlays or the `host` target.
 
 ## Quick Reference
 
 | Action | Command | Description |
 |--------|---------|-------------|
-| Apply container deploy | `charly fleet add <name> <ref>` | Compile candies + build overlay if `add_candy:` present + run via quadlet |
-| Apply local deploy | `charly fleet add <name> <ref>` (entry with a `local:` substrate node) | Apply layers directly to local filesystem (see [`/charly-local:local-deploy`](/recipes/local/local-deploy/)) |
-| Tear down deploy | `charly fleet del <name>` | Stop container + reverse ReverseOps (host) + ledger cleanup |
-| Dry-run | `charly fleet add <name> <ref> --dry-run [--format=json]` | Print the InstallPlan without executing |
-| Layer overlay | `charly fleet add <name> <ref> --add-candy <ref>` | Extra layer(s) applied on top; repeatable |
+| Apply container deploy | `charly deploy add <name> <ref>` | Compile candies + build overlay if `add_candy:` present + run via quadlet |
+| Apply local deploy | `charly deploy add <name> <ref>` (entry with a `local:` substrate node) | Apply layers directly to local filesystem (see [`/charly-local:local-deploy`](/recipes/local/local-deploy/)) |
+| Tear down deploy | `charly deploy del <name>` | Stop container + reverse ReverseOps (host) + ledger cleanup |
+| Dry-run | `charly deploy add <name> <ref> --dry-run [--format=json]` | Print the InstallPlan without executing |
+| Layer overlay | `charly deploy add <name> <ref> --add-candy <ref>` | Extra layer(s) applied on top; repeatable |
 | Configure deployment | `charly config <image>` | Generate .container file + save charly.yml |
 | Configure instance | `charly config <image> -i <instance>` | Generate instance-specific quadlet + deploy entry |
 | Configure volume backing | `charly config <image> --bind name` | Set volume as host bind mount |
 | Provision data | `charly config <image> --seed` | Auto-provision data candies into bind mounts (default) |
-| Deploy status | `charly fleet status` | Audit charly.yml vs quadlet sync |
-| Show overrides | `charly fleet show [image]` | Display charly.yml contents |
-| Show instance overrides | `charly fleet show <image> -i <instance>` | Display instance-specific overrides |
-| Import config | `charly fleet import <files>` | Merge files into charly.yml |
-| Reset config | `charly fleet reset [image]` | Remove charly.yml overrides |
-| Reset instance config | `charly fleet reset <image> -i <instance>` | Remove instance overrides |
+| Deploy status | `charly deploy status` | Audit charly.yml vs quadlet sync |
+| Show overrides | `charly deploy show [image]` | Display charly.yml contents |
+| Show instance overrides | `charly deploy show <image> -i <instance>` | Display instance-specific overrides |
+| Import config | `charly deploy import <files>` | Merge files into charly.yml |
+| Reset config | `charly deploy reset [image]` | Remove charly.yml overrides |
+| Reset instance config | `charly deploy reset <image> -i <instance>` | Remove instance overrides |
 | Push to registry | `charly box build --push` | Multi-platform push |
 
-For service lifecycle commands (start/stop/status/logs/update/remove), see [`/charly-core:service`](/recipes/core/service/). For VM lifecycle (build/create/start/stop/ssh), see [`/charly-vm:vm`](/recipes/vm/vm/); for in-VM layer deploys via `charly fleet add vm:<name>`, see the "VM target" section below and [`/charly-internals:vm-deploy-target`](/recipes/internals/vm-deploy-target/). For encrypted storage, see [`/charly-automation:enc`](/recipes/automation/enc/). For host-target semantics, see [`/charly-local:local-deploy`](/recipes/local/local-deploy/). For Kubernetes targets, see [`/charly-kubernetes:kubernetes`](/recipes/kubernetes/kubernetes/). For the Go IR that drives all five targets, see [`/charly-internals:install-plan`](/recipes/internals/install-plan/).
+For service lifecycle commands (start/stop/status/logs/update/remove), see [`/charly-core:service`](/recipes/core/service/). For VM lifecycle (build/create/start/stop/ssh), see [`/charly-vm:vm`](/recipes/vm/vm/); for in-VM layer deploys via `charly deploy add vm:<name>`, see the "VM target" section below and [`/charly-internals:vm-deploy-target`](/recipes/internals/vm-deploy-target/). For encrypted storage, see [`/charly-automation:enc`](/recipes/automation/enc/). For host-target semantics, see [`/charly-local:local-deploy`](/recipes/local/local-deploy/). For Kubernetes targets, see [`/charly-kubernetes:kubernetes`](/recipes/kubernetes/kubernetes/). For the Go IR that drives all five targets, see [`/charly-internals:install-plan`](/recipes/internals/install-plan/).
 
 ## Command Family: `add` / `del`
 
-### `charly fleet add <name> [<ref>]`
+### `charly deploy add <name> [<ref>]`
 
 Applies a deployment. The substrate node selects the target:
 
@@ -96,7 +96,7 @@ Disambiguation: a ref containing `/candy/` resolves to a candy; `/box/` to a box
 
 When `<ref>` is omitted, the ref falls back to the deploy's `image:` field (or the deploy key itself if no explicit image is declared).
 
-### `charly fleet add` flags
+### `charly deploy add` flags
 
 **Universal:**
 - `--tag <calver>` — override charly.yml tag
@@ -106,6 +106,21 @@ When `<ref>` is omitted, the ref falls back to the deploy's `image:` field (or t
 - `--verify` — run layer `check:` post-deploy
 - `--add-candy <ref>` — repeatable; extra layer(s) applied on top (all 4 ref forms)
 
+**Per-deploy selector overrides** — the deploy-entity level of the resolution chain
+`flag > deploy entity > env > settings file > built-in default`. Each value is validated
+against the schema-owned vocabulary, applied to the deploy for this run, and persisted onto
+the deploy entry so the next load resolves the same value:
+- `--engine <word>` — container engine for a `pod:` deploy (`auto`, or a member of the spec
+  engine vocabulary). A composed candy whose `engine:` constraint disagrees is an error,
+  never an override.
+- `--backend <word>` — VM backend for a `vm:` deploy (`auto`, or a member of the spec
+  VM-backend vocabulary; `krun` is explicit-only and never auto-detected).
+- `--namespace <name>` — containerd namespace for a `pod:` deploy. A per-deploy value
+  overrides `containerd.namespace` in the settings file, which overrides the engine
+  capability's default.
+- `--rootful <mode>` — rootful-launch mode for a `pod:` deploy (a member of the spec
+  rootful vocabulary).
+
 **Local-target-specific** (silently ignored on pod deploys):
 - `--with-services` — opt-in for systemd unit installation (packaged-unit enable + drop-ins)
 - `--allow-repo-changes` — opt-in for repo config mutations (rpmfusion, copr, external `.repo` files)
@@ -114,28 +129,28 @@ When `<ref>` is omitted, the ref falls back to the deploy's `image:` field (or t
 - `--builder-image <ref>` — override the compile-builder image
 - `--assume-yes` / `-y` — all three gates plus skip sudo preflight
 
-### `charly fleet del <name>`
+### `charly deploy del <name>`
 
 Reverses a deployment. Gated host-side reversal respects `--keep-repo-changes` and `--keep-services`. Container teardown: `podman stop` + `rm` + overlay image removal (unless `--keep-image`) + ledger cleanup. VM teardown: SSH-executed ReverseOps in the guest, preserving the VM itself (use `charly vm destroy` separately). See [`/charly-local:local-deploy`](/recipes/local/local-deploy/) for the full 15-kind ReverseOp table.
 
-## VM target: `charly fleet add vm:<vm-name> <ref>`
+## VM target: `charly deploy add vm:<vm-name> <ref>`
 
 Applies layer recipes **inside a running VM** over SSH. Same `InstallPlan` IR as host and container targets; the difference is that bash bodies run via `ssh guest 'sudo bash -s'` through an `SSHExecutor` (see [`/charly-internals:vm-deploy-target`](/recipes/internals/vm-deploy-target/)).
 
-**Prerequisite**: the VM must exist before `charly fleet add vm:...` runs. `charly fleet add vm:<name>` does NOT auto-provision; a missing VM produces a clean error pointing at `charly vm create`:
+**Prerequisite**: the VM must exist before `charly deploy add vm:...` runs. `charly deploy add vm:<name>` does NOT auto-provision; a missing VM produces a clean error pointing at `charly vm create`:
 
 ```bash
 charly vm create arch                            # provision VM first
-charly fleet add vm:arch ripgrep                # then apply layer in guest
-charly fleet add vm:arch fedora-coder \
+charly deploy add vm:arch ripgrep                # then apply layer in guest
+charly deploy add vm:arch fedora-coder \
     --add-candy team-extras \
     --add-candy github.com/team/configs/candy/sshkeys
-charly fleet del vm:arch                        # reverse all applied layers (VM stays up)
+charly deploy del vm:arch                        # reverse all applied layers (VM stays up)
 ```
 
 ### `VmDeployState` schema in charly.yml
 
-When `charly fleet add vm:<name>` completes, a `vm_state:` block lands inline in the charly.yml deploy:
+When `charly deploy add vm:<name>` completes, a `vm_state:` block lands inline in the charly.yml deploy:
 
 ```yaml
 arch:                                          # the deploy name; addressable as vm:arch
@@ -159,17 +174,17 @@ arch:                                          # the deploy name; addressable as
 
 ### Marking a deploy VM-targeted: the `vm:` substrate node
 
-A deploy is VM-targeted when its first child key is the `vm:` substrate node carrying `from: <entity>` — there is no `target:` field. CLI dispatch additionally accepts a `vm:<vm-name>` prefix on the deploy-name argument (`charly fleet add vm:arch`), which `ResolveTarget` reads to route through `pluginDeployTarget` (S3b — the adapter for the external `vm` substrate, dispatched through `candy/plugin-fleet`'s `Invoke(OpDeployDispatch)`). The prefix is an addressing convenience; the `vm:` substrate node is the source of truth. Naming a `vm:` deploy whose `vm` entity isn't declared in `charly.yml` errors at `charly fleet add` time; a declared-but-unbooted VM is auto-booted by the vm deploy plugin's `OpPrepareVenue`.
+A deploy is VM-targeted when its first child key is the `vm:` substrate node carrying `from: <entity>` — there is no `target:` field. CLI dispatch additionally accepts a `vm:<vm-name>` prefix on the deploy-name argument (`charly deploy add vm:arch`), which `ResolveTarget` reads to route through `pluginDeployTarget` (S3b — the adapter for the external `vm` substrate, dispatched through `candy/plugin-fleet`'s `Invoke(OpDeployDispatch)`). The prefix is an addressing convenience; the `vm:` substrate node is the source of truth. Naming a `vm:` deploy whose `vm` entity isn't declared in `charly.yml` errors at `charly deploy add` time; a declared-but-unbooted VM is auto-booted by the vm deploy plugin's `OpPrepareVenue`.
 
 ### `add_candy:` overlay semantics for VM targets
 
-When `charly fleet add vm:<name> <ref>` runs with `--add-candy`, the extra layers are applied **inside the guest** alongside the primary ref. The compiler merges `<ref>` + `add_candy:` into a single topo-sorted `InstallPlan`; the external `deploy:vm` plugin's `kit.WalkPlans` walks it inside the guest over SSH. The host-side ledger (keyed by `computeDeployID`) records both the base and overlay layers' teardown ops so `charly fleet del vm:<name>` reverses the full set.
+When `charly deploy add vm:<name> <ref>` runs with `--add-candy`, the extra layers are applied **inside the guest** alongside the primary ref. The compiler merges `<ref>` + `add_candy:` into a single topo-sorted `InstallPlan`; the external `deploy:vm` plugin's `kit.WalkPlans` walks it inside the guest over SSH. The host-side ledger (keyed by `computeDeployID`) records both the base and overlay layers' teardown ops so `charly deploy del vm:<name>` reverses the full set.
 
 This is the same merge semantics as a `local:` deploy — just with SSH-wrapped execution. See [`/charly-internals:install-plan`](/recipes/internals/install-plan/) for the compiler and [`/charly-internals:vm-deploy-target`](/recipes/internals/vm-deploy-target/) for the execution model.
 
 ### VM-relevant `install_opts:` fields
 
-`install_opts:` in the charly.yml entry mirrors the CLI flags on `charly fleet add`. For VM targets, the relevant ones are:
+`install_opts:` in the charly.yml entry mirrors the CLI flags on `charly deploy add`. For VM targets, the relevant ones are:
 
 | Field | Effect |
 |---|---|
@@ -188,8 +203,8 @@ charly.yml declares a vm entity (`<name>: {vm: …}`)
     → charly vm build <name>         (cloud_image: fetch+resize+seed ISO; bootc: install to-disk)
     → charly vm create <name>        (libvirt domain + SMBIOS ssh key + passt portForward)
     → charly vm start <name>         (boot)
-    → charly fleet add vm:<name> <ref>  (SSH → cloud-init wait → charly install → layer apply)
-    → charly fleet del vm:<name>    (SSH → ReverseOps; VM stays up)
+    → charly deploy add vm:<name> <ref>  (SSH → cloud-init wait → charly install → layer apply)
+    → charly deploy del vm:<name>    (SSH → ReverseOps; VM stays up)
     → charly vm destroy <name>       (remove libvirt domain; --disk to also delete qcow2)
 ```
 
@@ -199,7 +214,7 @@ See [`/charly-vm:vms-catalog`](/recipes/vm/vms-catalog/) for vm-entity authoring
 
 Both container and host targets accept extra candies at deploy time via `--add-candy <ref>` (repeatable) or the deploy's inline `add_candy:` list. Semantics:
 
-- **Container target**: synthesizes an overlay Containerfile (`FROM <base-image>` + the extra candies' build steps) and builds a deterministic overlay image tagged `<deploy-name>-overlay:<short-hash>`. The deploy runs the overlay, not the base image. Re-running with different overlays rebuilds. `charly fleet del <name>` removes the overlay unless `--keep-image`.
+- **Container target**: synthesizes an overlay Containerfile (`FROM <base-image>` + the extra candies' build steps) and builds a deterministic overlay image tagged `<deploy-name>-overlay:<short-hash>`. The deploy runs the overlay, not the base image. Re-running with different overlays rebuilds. `charly deploy del <name>` removes the overlay unless `--keep-image`.
 - **Host target**: the compiler merges the box's candies with `add_candy:`, topo-sorts the union, and compiles one `InstallPlan` covering the combined set. The ledger records which candies (base + overlay) were applied so teardown reverses everything.
 
 Ref forms for `--add-candy` are identical to the primary `<ref>` positional (local name / local path / remote / legacy `@` form).
@@ -402,26 +417,26 @@ added since. Requiring `image:` makes the inspected image deterministic.
 
 **Deploy a local image as a container:**
 ```bash
-charly fleet add my-dev fedora-coder
+charly deploy add my-dev fedora-coder
 # Uses the my-dev deploy's inline volume/port/env/tunnel config.
-charly fleet del my-dev
+charly deploy del my-dev
 ```
 
 **Deploy directly to the host:**
 ```bash
-charly fleet add host fedora-coder --with-services --assume-yes
-charly fleet del host --assume-yes
+charly deploy add host fedora-coder --with-services --assume-yes
+charly deploy del host --assume-yes
 ```
 
 **Deploy from a remote repo:**
 ```bash
-charly fleet add my-coder github.com/opencharly/charly/box/fedora-coder@main
-charly fleet add host github.com/team-acme/private-configs/candy/my-team-tools
+charly deploy add my-coder github.com/opencharly/charly/box/fedora-coder@main
+charly deploy add host github.com/team-acme/private-configs/candy/my-team-tools
 ```
 
 **Add overlay layers:**
 ```bash
-charly fleet add host fedora-coder \
+charly deploy add host fedora-coder \
     --add-candy team-extras \
     --add-candy github.com/team/configs/candy/sshkeys \
     --add-candy ./private.yml \
@@ -430,13 +445,13 @@ charly fleet add host fedora-coder \
 
 **Dry-run to preview the plan:**
 ```bash
-charly fleet add host fedora-coder --dry-run --format=json
+charly deploy add host fedora-coder --dry-run --format=json
 ```
 
 **`charly start`/`charly stop` equivalence:**
 ```bash
-charly start fedora-coder            # == charly fleet add fedora-coder fedora-coder (container target)
-charly stop fedora-coder             # == charly fleet del fedora-coder
+charly start fedora-coder            # == charly deploy add fedora-coder fedora-coder (container target)
+charly stop fedora-coder             # == charly deploy del fedora-coder
 ```
 
 ## Quadlet Generation
@@ -471,7 +486,7 @@ Source: `sdk/deploykit/security.go`, `sdk/deploykit/quadlet.go`.
 
 ### Image Transfer
 
-When `engine.build=docker`, `charly config` auto-detects if the image is missing from podman and transfers via `docker save | podman load`. `charly update` re-transfers if needed.
+When `engine.run=docker`, `charly config` auto-detects if the image is missing from podman and transfers via `docker save | podman load`. `charly update` re-transfers if needed.
 
 Source: `sdk/deploykit/quadlet.go` + `sdk/deploykit/quadlet_pod.go` (generation), `charly/commands.go` (command structs).
 
@@ -580,7 +595,7 @@ Port protocols are stored in the `ai.opencharly.port_proto` image label so deplo
 
 **Critical:** When deploying instances with `charly config setup -i <name>`, tunnel config is NOT auto-inherited from the base image's charly.yml entry. Each instance must have its own `tunnel:` section in charly.yml. Without it, the generated quadlet will have no `ExecStartPost=tailscale serve` commands and the instance will be unreachable via Tailscale.
 
-**Root cause:** `labels.go:238` deliberately skips parsing the `ai.opencharly.tunnel` OCI label — tunnel is charly.yml-only. When `charly config setup` creates a new instance, it writes ports/env/security to charly.yml but does not copy tunnel from the base entry.
+**Root cause:** `sdk/deploykit/capabilities.go` deliberately skips parsing the `ai.opencharly.tunnel` OCI label — tunnel is charly.yml-only. When `charly config setup` creates a new instance, it writes ports/env/security to charly.yml but does not copy tunnel from the base entry.
 
 **Workaround:** After `charly config setup -i <name>`, manually edit `~/.config/charly/charly.yml` to add `tunnel: {provider: tailscale, private: all}` to the instance entry, then re-run `charly config setup -i <name>` to regenerate the quadlet.
 
@@ -597,19 +612,18 @@ Source: `sdk/deploykit/tunnel_resolve.go` (resolution + the shared `schemeTarget
 ### How it gets populated
 
 1. **`charly config`** automatically persists: workspace, ports, env (CLI -e), env_file, network, security (auto-detected devices), volume backing (--bind/--encrypt)
-2. **`charly fleet import`** merges pre-provisioned config (tunnel, volumes, DNS) from files
+2. **`charly deploy import`** merges pre-provisioned config (tunnel, volumes, DNS) from files
 3. **`charly remove`** cleans the entry (use `--keep-deploy` to preserve for re-config)
 
 ### Legacy-schema rejection
 
-The per-host config is compact node-form: top-level name-first `<name>: {<substrate-kind>: <full body>}` entries (the substrate-kind being `pod`/`vm`/`kubernetes`/`local`/`android`/`group`, its value carrying the deploy config INLINE, projected internally into the `FleetConfig.Fleet` map; the only named children are member sub-entities), preceded by a `version:` stamp and an optional `provides:` directive. `LoadFleetConfig` reads it through the unified node-form loader (`LoadUnified` → `ProjectFleetConfig`). A host still on a legacy root shape — the obsolete `image:`/`images:` root key, or the legacy `deploy.yml` filename — is detected and fails loud, so a misparse can never silently drop a `volume:` entry with `type: encrypted` — the encrypted-volume load is `LoadEncryptedVolume` (sdk/deploykit/enc_probe.go) — and quietly void the encryption guarantee; the failure points at `charly migrate`.
+The per-host config is compact node-form: top-level name-first `<name>: {<substrate-kind>: <full body>}` entries (the substrate-kind being `pod`/`vm`/`kubernetes`/`local`/`android`/`group`, its value carrying the deploy config INLINE, projected internally into the `DeployConfig.Deploy` map; the only named children are member sub-entities), with an optional top-level `provides:` directive. `LoadDeployConfig` reads it through the unified node-form loader (`LoadUnified` → `ProjectDeployConfig`). A host still on a legacy root shape — the obsolete `image:`/`images:` root key, or the legacy `deploy.yml` filename — is detected and fails loud, so a misparse can never silently drop a `volume:` entry with `type: encrypted` — the encrypted-volume load is `LoadEncryptedVolume` (sdk/deploykit/enc_probe.go) — and quietly void the encryption guarantee; the failure points at `charly migrate`.
 
-`charly status` surfaces this as a non-fatal warning (graceful degradation falls back to image-label-driven display); the strictly-charly.yml-driven verbs (`charly fleet show`, `charly config status`, `charly start`) hard-fail. Run `charly migrate` to convert in place — it backs the original up to `<file>.bak.<unix-ts>` and rewrites to the latest schema. See [`/charly-build:migrate`](/recipes/build/migrate/) "charly migrate".
+`charly status` surfaces this as a non-fatal warning (graceful degradation falls back to image-label-driven display); the strictly-charly.yml-driven verbs (`charly deploy show`, `charly config status`, `charly start`) hard-fail. Run `charly migrate` to convert in place — it writes a rollback copy under the gitignored `<project>/.charly/backups/` tree and rewrites to the current schema. See [`/charly-build:migrate`](/recipes/build/migrate/) "charly migrate".
 
 ### Structure
 
 ```yaml
-version: 2026.186.2323
 my-app:
   pod:
     image: my-app
@@ -643,13 +657,13 @@ Per-deploy fields: the substrate node (`pod`/`vm`/`kubernetes`/`local`/`android`
 
 ### The substrate node, `add_candy:`, and `install_opts:` fields
 
-The `charly fleet add`/`del` surface honors these per deploy, each only when relevant to the resolved target.
+The `charly deploy add`/`del` surface honors these per deploy, each only when relevant to the resolved target.
 
 **The substrate node** — `pod:` (the default, carrying `image:`), `vm:`, `kubernetes:`, `local:`, or `android:` (carrying `from:`) selects the target; there is no `target:` field. A local deploy carries the Ansible-style `host:` scalar (`host: local`, the default, runs directly; `host: <user@machine>` runs over SSH) and applies its `add_candy:` candies to the host filesystem.
 
 **`add_candy:`** — an inline list of extra layer refs applied on top of the image's base layers. Each entry accepts the same 4 ref forms as the command-line `--add-candy` flag (local name / local YAML path / remote `github.com/.../candy/<n>[@ref]`). See "add_candy: overlay mechanism" above for pod vs local semantics.
 
-**`install_opts:`** — an inline block of local-target defaults that mirror the CLI flags on `charly fleet add`. CLI flags win on conflict; the deploy provides defaults so you don't have to repeat `--with-services --allow-repo-changes` on every invocation.
+**`install_opts:`** — an inline block of local-target defaults that mirror the CLI flags on `charly deploy add`. CLI flags win on conflict; the deploy provides defaults so you don't have to repeat `--with-services --allow-repo-changes` on every invocation.
 
 ```yaml
 my-host:
@@ -771,7 +785,7 @@ charly config my-app                               # Picks up volumes from charl
 ### Deploy status audit
 
 ```bash
-charly fleet status
+charly deploy status
 # sway-browser-vnc              charly.yml: yes  quadlet: yes  (ok)
 # old-service                   charly.yml: yes  quadlet: no   (stale config)
 # manual-service                charly.yml: no   quadlet: yes  (no overrides)
@@ -819,9 +833,9 @@ selkies-desktop/personal:
     port: ["3002:3000"]
 ```
 
-**Instance lifecycle:** All commands accept `-i`: `charly start/stop/status/logs/remove <image> -i <instance>`, `charly fleet show/reset <image> -i <instance>`. Removing an instance only cleans its charly.yml entry — the base and other instances are unaffected. Provides cleanup waits until the last entry for a base image is removed.
+**Instance lifecycle:** All commands accept `-i`: `charly start/stop/status/logs/remove <image> -i <instance>`, `charly deploy show/reset <image> -i <instance>`. Removing an instance only cleans its charly.yml entry — the base and other instances are unaffected. Provides cleanup waits until the last entry for a base image is removed.
 
-**Instance removal gotcha:** `charly config remove` disables the quadlet service but does NOT remove the charly.yml entry and does NOT delete the quadlet file. `charly remove <image> -i <instance>` is the complete teardown (stops the container, deletes the quadlet file, reloads systemd); `charly fleet reset <image> -i <instance>` removes the charly.yml entry. If you run `charly config --update-all` before cleaning charly.yml, stale quadlet files will be re-created. See [`/charly-core:charly-config`](/recipes/core/charly-config/) for the removal semantics.
+**Instance removal gotcha:** `charly config remove` disables the quadlet service but does NOT remove the charly.yml entry and does NOT delete the quadlet file. `charly remove <image> -i <instance>` is the complete teardown (stops the container, deletes the quadlet file, reloads systemd); `charly deploy reset <image> -i <instance>` removes the charly.yml entry. If you run `charly config --update-all` before cleaning charly.yml, stale quadlet files will be re-created. See [`/charly-core:charly-config`](/recipes/core/charly-config/) for the removal semantics.
 
 **MCP name disambiguation:** When an instance provides MCP servers, the server name gets `-<instance>` appended (e.g., `chrome-devtools-work`). See [`/charly-core:charly-config`](/recipes/core/charly-config/) for details.
 
@@ -1158,17 +1172,17 @@ webapp:                            # an operator deploy + a companion member
 
 - **Folded to addressable top-level entries.** At load time `foldMembers` reads each
   tree-position member into the internal `.Members` map and registers it as a top-level
-  Fleet entry (so `charly config <member>` / `charly start <member>` resolve it
+  Deploy entry (so `charly config <member>` / `charly start <member>` resolve it
   through the exact path any deploy uses) carrying a derived `MemberOf: <owner>`. A
   member name must be **globally unique** (a collision with any deploy/bed/member is
   a hard load error) and carry **no `.`** (same rules as nested-member keys + bed
   names); the author keeps member **host ports disjoint** (the loader does not check
   ports — port absence, i.e. auto-allocation, avoids fixed-port collisions).
-- **One shared lifecycle (R3).** `BringUpMembers` / `TearDownMembers` (`sdk/deploykit/fleet_members.go`)
+- **One shared lifecycle (R2).** `BringUpMembers` / `TearDownMembers` (`sdk/deploykit/deploy_members.go`)
   bring members up after the owner and tear them down with it, by shelling out to the
   SAME verbs — a pod member via `charly config` + `charly start` (+ readiness wait), a
-  non-pod member via `charly fleet add` / `charly fleet del`. Wired into `charly fleet add` /
-  `charly fleet del` (operator path) AND the disposable-deploy bed runner (the bed's
+  non-pod member via `charly deploy add` / `charly deploy del`. Wired into `charly deploy add` /
+  `charly deploy del` (operator path) AND the disposable-deploy bed runner (the bed's
   `--node-only` add never double-deploys; the runner brings members up after the root
   starts). A bed's `charly update` (destroy + rebuild) tears members down and back up too.
 - **Disposability is inherited, never invented.** `foldMembers` promotes a member to
@@ -1197,16 +1211,16 @@ webapp:                            # an operator deploy + a companion member
 - [`/charly-build:pull`](/recipes/build/pull/) — Prerequisite: fetch the image into local storage; handles remote refs (`@github.com/...`) and the `ErrImageNotLocal` recovery path
 - [`/charly-automation:sidecar`](/recipes/automation/sidecar/) — Sidecar containers, pod networking, Tailscale exit nodes, Environment Contract (provides filtering)
 - [`/charly-core:service`](/recipes/core/service/) — Service lifecycle (start/stop/update/remove)
-- [`/charly-core:start`](/recipes/core/start/) — Ergonomic alias for `charly fleet add <image> <image>` (container target)
-- [`/charly-core:stop`](/recipes/core/stop/) — Ergonomic alias for `charly fleet del <name>`
-- [`/charly-core:charly-update`](/recipes/core/charly-update/) — Per-instance update pattern; equivalent to `charly fleet add <name> --pull`
+- [`/charly-core:start`](/recipes/core/start/) — Ergonomic alias for `charly deploy add <image> <image>` (container target)
+- [`/charly-core:stop`](/recipes/core/stop/) — Ergonomic alias for `charly deploy del <name>`
+- [`/charly-core:charly-update`](/recipes/core/charly-update/) — Per-instance update pattern; equivalent to `charly deploy add <name> --pull`
 - [`/charly-core:charly-config`](/recipes/core/charly-config/) — Resource cap flags (`--memory-max/high/swap/cpus`), provides filtering, env_require enforcement, NO_PROXY auto-enrichment, `--sidecar`, `-i` instance support, MCP name disambiguation
 - [`/charly-automation:enc`](/recipes/automation/enc/) — Encrypted storage commands (charly config mount/unmount)
 - [`/charly-check:vnc`](/recipes/check/vnc/) — VNC password setup for desktop containers
 - [`/charly-vm:vm`](/recipes/vm/vm/) — Virtual machine deployment (charly vm)
 - [`/charly-build:build`](/recipes/build/build/) — Building images before deployment (+ the `--no-cache` intermediate scratch-stage caveat)
 - [`/charly-build:charly-mcp-cmd`](/recipes/build/charly-mcp-cmd/) — verify the MCP endpoints declared by `provides.mcp:` entries are actually reachable (`charly check live <image> --filter mcp`); note the **port-publishing gotcha** when a `port:` override in charly.yml predates a newly-added mcp-providing layer
-- [`/charly-image:image`](/recipes/image/image/) — Image configuration, OCI label emission, `labels.go:238` tunnel read-skip
+- [`/charly-image:image`](/recipes/image/image/) — Image configuration, OCI label emission, `sdk/deploykit/capabilities.go` tunnel read-skip
 - [`/charly-image:layer`](/recipes/image/layer/) — Unified `service:` schema (use_packaged + structured custom), `env_provide`/`env_require`/`env_accept` field declarations, security resource caps
 - [`/charly-check:check`](/recipes/check/check/) — Local `check:` in charly.yml overlays image-baked deploy defaults: entries with matching `id:` replace, otherwise append. `id: X, skip: true` disables a baked check without a replacement.
 
@@ -1221,7 +1235,7 @@ webapp:                            # an operator deploy + a companion member
 
 A deploy's name lives alongside every other top-level entity in its document. Cross-kind reuse of a name across SEPARATE discovered files is fine (a `candy/redis` + a `box/redis` resolve to distinct internal maps), but two top-level entities WITHIN one document MUST NOT share a name — they would collide on one YAML key (`charly box validate` flags it). The convention is to keep the user-facing deploy name and **suffix** the template it deploys: this repo's `charly-cachyos` deploy carries `local: {from: charly-cachyos-app}`, referencing the distinct `charly-cachyos-app` kind:local template. A deploy's substrate node (`pod:`, `vm:`, `local:`, `kubernetes:`, `android:`) is scoped to the matching kind, no fall-through.
 
-`ResolveDeployRef` (used by `charly fleet add <name> <ref>`) is box-first: when a name exists as BOTH a box and a candy, the box wins for the primary `<ref>` positional. The `--add-candy <ref>` path goes through `ResolveDeployRefAsCandy`, which is candy-first. A same-name box and candy (in separate files) is permitted.
+`ResolveDeployRef` (used by `charly deploy add <name> <ref>`) is box-first: when a name exists as BOTH a box and a candy, the box wins for the primary `<ref>` positional. The `--add-candy <ref>` path goes through `ResolveDeployRefAsCandy`, which is candy-first. A same-name box and candy (in separate files) is permitted.
 
 The loader raises a hard load-time error on obsolete deploy names (the retired `qc` / `cachyos-dx` keys) and on any obsolete root shape (a `kind: deployment` / `deployment:` / `kind: deploy` / `deploy:` / `fleet:` document — the kind is now the name-first substrate-node (`pod:`/`vm:`/`kubernetes:`/`local:`/`android:`/`group:`) discriminator); every such error points at `charly migrate`. See [`/charly-build:migrate`](/recipes/build/migrate/).
 
diff --git a/src/content/docs/recipes/hermes/playwright-layer.md b/src/content/docs/recipes/hermes/playwright-layer.md
index 8aab0317..4a94c095 100644
--- a/src/content/docs/recipes/hermes/playwright-layer.md
+++ b/src/content/docs/recipes/hermes/playwright-layer.md
@@ -29,11 +29,9 @@ my-box:
 
 ## Used In Boxes
 
-- `openclaw-full` (via `openclaw-full` metalayer)
 
 ## Related Candies
 - [`/charly-coder:nodejs`](/recipes/coder/nodejs/) -- runtime dependency
-- [`/charly-openclaw:openclaw-full`](/recipes/openclaw/openclaw-full/) -- parent metalayer that bundles playwright
 - [`/charly-selkies:chrome`](/recipes/selkies/chrome/) -- browser commonly driven by playwright
 
 ## Related Commands
diff --git a/src/content/docs/recipes/infrastructure/tmux-layer.md b/src/content/docs/recipes/infrastructure/tmux-layer.md
index dd44870b..56ea777d 100644
--- a/src/content/docs/recipes/infrastructure/tmux-layer.md
+++ b/src/content/docs/recipes/infrastructure/tmux-layer.md
@@ -33,7 +33,6 @@ my-box:
 
 ## Used In Boxes
 
-- `openclaw-full` (via `openclaw-full` metalayer)
 
 ## Related Skills
 
diff --git a/src/content/docs/recipes/internals/agents/hooks-and-lifecycle.md b/src/content/docs/recipes/internals/agents/hooks-and-lifecycle.md
index b6d24e7e..aea18825 100644
--- a/src/content/docs/recipes/internals/agents/hooks-and-lifecycle.md
+++ b/src/content/docs/recipes/internals/agents/hooks-and-lifecycle.md
@@ -480,10 +480,13 @@ acting without the orchestrator's direct supervision.
 - **Session identity and scope claims are the comment grammar.** When two
   or more agents work one issue/PR, or a scope is a blocking dependency,
   a session speaks through its two-line `Agent:` + `Assisted-by` footer
-  and a scope is claimed or taken over only through the closed verb set
-  (`CLAIM`/`OWNING`/`HANDING OVER`/`TAKING OVER`/`WAITING`/`HOLDING`/
-  `CLEARED`/`STATUS`/`RESOLVED`). Owned by [`/charly-internals:git-workflow`](/recipes/internals/git-workflow/) B2b —
-  never restated here.
+  and a scope is claimed, handed over, taken over or reported only through
+  the coordination grammar's closed verb set. That set, what each label
+  means (which side of a block speaks, and what the resolution posts), the
+  required comment fields and the takeover window are stated once in
+  `AGENTS.md` Part II #7 and operationalized in
+  [`/charly-internals:git-workflow`](/recipes/internals/git-workflow/) B2b. The labels are not enumerated here:
+  a copy drifts, the pointer cannot.
 
 ## Todo ledger & interruption safety
 
diff --git a/src/content/docs/recipes/internals/git-workflow/pre-validator-self-audit.md b/src/content/docs/recipes/internals/git-workflow/pre-validator-self-audit.md
index 425c5800..0a21891f 100644
--- a/src/content/docs/recipes/internals/git-workflow/pre-validator-self-audit.md
+++ b/src/content/docs/recipes/internals/git-workflow/pre-validator-self-audit.md
@@ -208,7 +208,11 @@ compliance`, `## Change classification`); a trailer that is not the LAST line (o
 an `Agent:` line not directly preceding it); a rule with no answer, or a bare
 `N/A` with no reason (class 3); an asserted check with no LATER fenced block
 carrying a `$ ` command (class 6); a pasted head SHA that is not `git rev-parse
-HEAD` (class 1); and any ellipsis character inside a fence. Run it on the body
+HEAD` (class 1); and an AUTHORIAL elision inside a fence — an elided `$ `
+command line, an elided `head` command's output, or a dropped line of the
+paste. An ellipsis character that a PROGRAM printed in its own output is
+ALLOWED: the body pastes the product's output verbatim, so the product's own
+token is not an elision (`opencharly/marketplace#537`). Run it on the body
 file BEFORE the push:
 
 ```
diff --git a/src/content/docs/recipes/kubernetes/helm.md b/src/content/docs/recipes/kubernetes/helm.md
index ed79480e..9d37b792 100644
--- a/src/content/docs/recipes/kubernetes/helm.md
+++ b/src/content/docs/recipes/kubernetes/helm.md
@@ -61,29 +61,29 @@ an uninstall step yourself.
 ## The authoring law this surfaced: mutating installs live in a CANDY
 
 A bed's own plan runs **verify-only** (mutating steps skipped), and
-`charly fleet add` lowers only **candy** plans' `run:` steps. So any
+`charly deploy add` lowers only **candy** plans' `run:` steps. So any
 mutating install — the `helm-release` invocation itself, and any in-venue
 `kubectl wait` it depends on — MUST live in a candy's `run:` steps, never
 in the bed's own plan. Authoring the install into the bed produces a bed
 that passes while installing nothing.
 
 A second-order trap rides along: a `check:` step does **not** run during
-`fleet add`, so the `k3s-server` candy's own node-ready check cannot gate
+`deploy add`, so the `k3s-server` candy's own node-ready check cannot gate
 your install. An install candy waits for the node itself.
 
 **Two independent mechanisms decide when a step runs, and confusing them
 is the trap.**
 
-First the step KEYWORD. `charly fleet add` lowers `run:` steps and
+First the step KEYWORD. `charly deploy add` lowers `run:` steps and
 nothing else — `check:`, `agent-*:` and `include:` steps are never
 lowered, whatever `context:` they carry
 (`sdk/deploykit/install_build.go:694-697`, which drops non-`run:`
 keywords *before* it looks at context at all). So the `check:` step in
-the example below does not execute during `fleet add` **because it is a
+the example below does not execute during `deploy add` **because it is a
 `check:` step** — not because of its context. Giving it
 `context: [deploy]` would not change that.
 
-(This is about `fleet add` LOWERING. `context:` on a `check:` step is not
+(This is about `deploy add` LOWERING. `context:` on a `check:` step is not
 inert in general — it selects which CHECK MODE the step runs in, which is
 a different walk entirely; see "Author the STEP `context: [runtime]`"
 under `verb:helm` below.)
@@ -148,7 +148,7 @@ helm-chart:
 
 Three things about that readiness step are deliberate. **The `/readyz`
 poll is bounded and condition-driven**, with an explicit deadline and a
-non-zero exit — it is a synchronization primitive, not an R4
+non-zero exit — it is a synchronization primitive, not an R3
 `sleep`-and-hope; a bare `sleep 60` in its place is the workaround the
 rule forbids. **Waiting on the node alone is not enough**: on a cold
 cluster `kubectl wait node` runs before the apiserver answers at all, so
@@ -162,7 +162,7 @@ runs in its own shell, so that export does not reach the
 chain. The candy hardcodes the k3s path because it is a k3s-guest bed
 fixture; a candy for another venue would not.
 
-Note the Agent Driven Evaluation (ADE) split (R3) — ADE is the
+Note the Agent Driven Evaluation (ADE) split (R2) — ADE is the
 spec-is-the-test discipline owned by [`/charly-check:check`](/recipes/check/check/): the candy that
 installs the release also asserts it exists; the bed's own plan keeps only
 the deeper status/revision assertions.
@@ -195,7 +195,7 @@ makes sense under `charly check live` / `charly check run`.
 **Author the STEP `context: [runtime]`, and understand that this is what
 makes it skip under `charly check box` — not the verb's EXEC nature.**
 
-This does not contradict the `fleet add` rule above, and the two are worth
+This does not contradict the `deploy add` rule above, and the two are worth
 holding apart: THERE, `context:` is irrelevant because a `check:` step is
 never lowered at all; HERE, `context:` is decisive because it selects the
 check mode the step is active in. Different walks, different questions.
diff --git a/src/content/docs/recipes/local/local-deploy.md b/src/content/docs/recipes/local/local-deploy.md
index 5a3ad2aa..bb7cefb6 100644
--- a/src/content/docs/recipes/local/local-deploy.md
+++ b/src/content/docs/recipes/local/local-deploy.md
@@ -35,11 +35,11 @@ For VM destinations, `charly vm create <name>` writes a managed Host stanza into
 
 | Action | Command |
 |---|---|
-| Direct local | `charly fleet add my-laptop` (`host: local` is the default) |
-| SSH to remote | `charly fleet add ci-3` with `host: user@ci-3.lan` in charly.yml |
+| Direct local | `charly deploy add my-laptop` (`host: local` is the default) |
+| SSH to remote | `charly deploy add ci-3` with `host: user@ci-3.lan` in charly.yml |
 | Reference a template | `from: dev-workstation` inside the `local:` node |
-| Tear down | `charly fleet del <name>` |
-| Tear down, keep repo changes | `charly fleet del <name> --keep-repo-changes` |
+| Tear down | `charly deploy del <name>` |
+| Tear down, keep repo changes | `charly deploy del <name> --keep-repo-changes` |
 
 ## Three DIFFERENT remote surfaces — do not conflate them
 
diff --git a/src/content/docs/recipes/vm/vm.md b/src/content/docs/recipes/vm/vm.md
index ef52d742..9b8ad91f 100644
--- a/src/content/docs/recipes/vm/vm.md
+++ b/src/content/docs/recipes/vm/vm.md
@@ -20,8 +20,8 @@ description: "MUST be invoked before any work involving: virtual machines, `char
   # the DISPOSABLE DEPLOY the automation drives (create/snapshot/destroy it)
   my-produce: { vm: { from: my-base-vm, disposable: true } }
   ```
-  and keys EVERY verb to that deploy's domain with `--domain my-produce` (`vm create`, `vm stop`, `vm snapshot create`, `vm destroy`, and — for the bake — `vm bake --domain my-produce`). `charly vm bake --domain <deploy>` also sets the create's non-destructive `--keep-disk`, because a golden captured on the domain BACKS ONTO the domain's disk: recreating that disk would drop the golden's backing and the bake would boot an empty overlay. A bed that instead destroys the shared entity (or a domain it was not handed as `disposable: true`) is a B17 violation — authorization is derived from the destroyed TARGET, never from the bed's own name or its `lifecycle:` tag.
-- **`charly update <vm-entity-name>`** does NOT gate on `disposable:` — an explicit invocation rebuilds ANY target (destroy→create the domain, reuse the qcow2 disk unless `--build`, then re-apply the deploy's layers via the shared `fleet add` path). For a non-disposable, non-ephemeral target it prints a one-line transparency note (`noteUpdateDisposability`) and proceeds. The `disposable: true` flag stays load-bearing as the authorization for UNATTENDED autonomous destroy + rebuild (the project rulebook R10 (`AGENTS.md`)) and the check-runner's unattended fresh rebuild, NOT as an `charly update` capability check. See [`/charly-internals:disposable`](/recipes/internals/disposable/) and [`/charly-core:charly-update`](/recipes/core/charly-update/).
+  and keys EVERY verb to that deploy's domain with `--domain my-produce` (`vm create`, `vm stop`, `vm snapshot create`, `vm destroy`, and — for the bake — `vm bake --domain my-produce`). `charly vm bake --domain <deploy>` also sets the create's non-destructive `--keep-disk`, because a golden captured on the domain BACKS ONTO the domain's disk: recreating that disk would drop the golden's backing and the bake would boot an empty overlay. A bed that instead destroys the shared entity (or a domain it was not handed as `disposable: true`) is a DISP violation (the validator's disposable-only check) — authorization is derived from the destroyed TARGET, never from the bed's own name or its `lifecycle:` tag.
+- **`charly update <vm-entity-name>`** does NOT gate on `disposable:` — an explicit invocation rebuilds ANY target (destroy→create the domain, reuse the qcow2 disk unless `--build`, then re-apply the deploy's layers via the shared `deploy add` path). For a non-disposable, non-ephemeral target it prints a one-line transparency note (`noteUpdateDisposability`) and proceeds. The `disposable: true` flag stays load-bearing as the authorization for UNATTENDED autonomous destroy + rebuild (the project rulebook R10 (`AGENTS.md`)) and the check-runner's unattended fresh rebuild, NOT as an `charly update` capability check. See [`/charly-internals:disposable`](/recipes/internals/disposable/) and [`/charly-core:charly-update`](/recipes/core/charly-update/).
 
 ## Overview
 
@@ -104,7 +104,7 @@ To pass a physical GPU through to a VM and (e.g.) run a CUDA container inside it
 3. **In-guest driver** — a passthrough guest needs the actual kernel module, not
    just the userspace container toolkit. Apply a kernel-driver layer (it
    blacklists the in-tree driver, regenerates the initramfs, and declares
-   `reboot: true` so `charly fleet add vm:<name>` reboots the guest and waits for it
+   `reboot: true` so `charly deploy add vm:<name>` reboots the guest and waits for it
    to return). The `nvidia`-toolkit layer + `nvidia-ctk cdi generate` then makes
    the GPU available to containers via CDI (`--device nvidia.com/gpu=all`).
 
@@ -281,7 +281,7 @@ arch:
                                                    # Note also that #DistroID (14 ids, omarchy included) and the embedded `distro:` BUILD vocabulary are
                                                    # different sets, and the gap is SILENT: `buildVmSyntheticBox` resolves this field against
                                                    # the build vocabulary and on a miss leaves `img.Pkg` unset, so candy installation compiles
-                                                   # ZERO package steps while `fleet add` reports success. A schema-valid id is therefore not
+                                                   # ZERO package steps while `deploy add` reports success. A schema-valid id is therefore not
                                                    # automatically a resolvable one.
                                                    # Use a bare id: `ResolveDistro` strips at `:` but the cloud-init
                                                    # dispatches compare exactly, so `debian:13` yields `openssh`. (That sentence is about the
@@ -345,7 +345,7 @@ file: Cannot lock pid file: Resource temporarily unavailable`) and
 corrupted the VM's state — every `charly check run <vm-bed>`'s
 `update` step failed with this error, even running sequentially.
 The same `vmshared.QemuAlive` probe drives the `vm list` qemu
-state scan and the preempt arbiter's holder probe (R3, one
+state scan and the preempt arbiter's holder probe (R2, one
 liveness probe).
 
 **Socket path probing for libvirt ≥ 8.0**: modular libvirt splits into `virtqemud` / `virtnetworkd` / ... — the socket is `virtqemud-sock`, not `libvirt-sock`. `libvirtSessionSocket()` probes `virtqemud-sock` first, falls back to `libvirt-sock` on older setups. Symptom of a misprobe: `ConnectToURI(QEMUSession)` returns `End of file while reading data: Input/output error` — means the daemon isn't accepting on the socket you reached.
@@ -549,12 +549,12 @@ per-deploy domain.
 
 ```bash
 charly vm create arch
-charly fleet add vm:arch ripgrep         # apply ripgrep layer over SSH
-charly fleet add vm:arch fedora-coder --add-candy team-extras
-charly fleet del vm:arch                 # reverse all applied layers
+charly deploy add vm:arch ripgrep         # apply ripgrep layer over SSH
+charly deploy add vm:arch fedora-coder --add-candy team-extras
+charly deploy del vm:arch                 # reverse all applied layers
 ```
 
-See [`/charly-core:deploy`](/recipes/core/deploy/) "vm: target" for the `charly fleet add vm:<name>` surface and [`/charly-internals:vm-deploy-target`](/recipes/internals/vm-deploy-target/) for the executor model.
+See [`/charly-core:deploy`](/recipes/core/deploy/) "vm: target" for the `charly deploy add vm:<name>` surface and [`/charly-internals:vm-deploy-target`](/recipes/internals/vm-deploy-target/) for the executor model.
 
 ### Debug VM boot issues
 
@@ -598,6 +598,31 @@ When `firmware: uefi-insecure` or `firmware: uefi-secure`, each VM gets its own
 
 Cloud-init `packages: [spice-vdagent]` pulls GTK3 + X11 (~200 MB download, ~1 GB installed). Running at 2 GiB RAM stalls cloud-init. **Check host inventory (`free -h`, `nproc`) before sizing** — give the VM what it needs (8 GiB + 4 cpus for a desktop-class workload is reasonable on a 16-core / 61 GiB host). See [`/charly-vm:arch-cloud-vm`](/recipes/vm/arch-cloud-vm/) Finding C for the live-test bisect.
 
+### Rootless podman cannot run the privileged VM builder — set `engine.rootful=sudo`
+
+On a host whose default engine is **rootless podman**, `charly vm build` fails
+inside the privileged bootstrap builder (pacstrap / debootstrap) with:
+
+```
+mount: /target/sys: permission denied.
+==> ERROR: failed to setup chroot /target
+```
+
+The cause is the user NAMESPACE, not sysfs itself: `--privileged` in a rootless
+container has no `CAP_SYS_ADMIN` equivalent for arbitrary bind mounts, so
+pacstrap's `mount --rbind` of the locked `/sys` is denied. The remedy is one
+setting — `sudo podman` runs the builder in the host namespace and bypasses it:
+
+```bash
+charly settings set engine.rootful sudo
+```
+
+Symptom without it is exactly the `mount: /target/sys: permission denied` line
+above (the build gets through the image tag, then dies at the chroot). The
+SDK's `buildkit/privileged_runner.go` carries this rationale in a code comment;
+the rootful ↔ rootless storage split this setting also causes is documented in
+the next section.
+
 ### Rootful ↔ rootless podman storage split (bootc)
 
 Under `engine.rootful=sudo`, `charly vm build` invokes `sudo podman` which reads from `/var/lib/containers/storage`, not your rootless storage. After every `charly box build`, refresh:
@@ -620,7 +645,7 @@ rm /tmp/bootc.tar
 charly vm build <name> --transport containers-storage
 ```
 
-`--transport containers-storage` forces `bootc install` to pull from the machine's local store. Worked example: [`/charly-openclaw:openclaw-desktop`](/recipes/openclaw/openclaw-desktop/) "Two-level nested-virtualization proof".
+`--transport containers-storage` forces `bootc install` to pull from the machine's local store.
 
 ### `charly vm destroy` — the DEPLOY name keys the domain (`--domain`) and missing targets are strict
 
@@ -646,12 +671,12 @@ no such VM "charly-definitely-not-a-vm-xyz": no libvirt domain and no qemu state
 exit=1
 ```
 
-### `charly fleet add vm:<vm> <localpkg-candy>` exits 0 WITHOUT installing
+### `charly deploy add vm:<vm> <localpkg-candy>` exits 0 WITHOUT installing
 
 A candy carrying a `local_pkg` block (the `charly` toolchain) needs the package
 built via the `charly generate-packages` plugin (nFPM) from local source, which
 only the check-bed runner does (it sets `--dev-local-pkg` automatically — see
-[`/charly-check:check`](/recipes/check/check/)). A bare `charly fleet add
+[`/charly-check:check`](/recipes/check/check/)). A bare `charly deploy add
 vm:<vm> charly` returns **rc=0** and prints:
 
 ```
@@ -693,11 +718,10 @@ Expected. The agent needs a `virtio-serial` channel that charly's QEMU backend d
 - [`/charly-internals:ovmf`](/recipes/internals/ovmf/) — UEFI firmware path resolution; per-VM NVRAM; bios-skips-loader sentinel
 - [`/charly-internals:cutover-policy`](/recipes/internals/cutover-policy/) — hard cutover policy
 - [`/charly-build:migrate`](/recipes/build/migrate/) — `charly migrate` legacy conversion
-- [`/charly-core:deploy`](/recipes/core/deploy/) — `charly fleet add vm:<name> <ref>` in-guest layer application
+- [`/charly-core:deploy`](/recipes/core/deploy/) — `charly deploy add vm:<name> <ref>` in-guest layer application
 - [`/charly-build:pull`](/recipes/build/pull/) — fetch container images into local storage (prereq for bootc VM builds)
 - [`/charly-build:build`](/recipes/build/build/) — building container images before VM disk builds
 - [`/charly-image:layer`](/recipes/image/layer/) — `libvirt.snippets:` field in charly.yml
-- [`/charly-openclaw:openclaw-desktop`](/recipes/openclaw/openclaw-desktop/) — two-level nested-virtualization proof
 - [`/charly-distros:cloud-init`](/recipes/distros/cloud-init/) — guest-side cloud-init package (complements host-side seed ISO rendering)
 - [`/charly-distros:qemu-guest-agent`](/recipes/distros/qemu-guest-agent/) — virtio-serial channel
 
@@ -705,6 +729,6 @@ Expected. The agent needs a `virtio-serial` channel that charly's QEMU backend d
 
 **MUST be invoked** when the task involves virtual machines, charly vm commands, kind:vm entities, cloud_image vs bootc source types, libvirt/QEMU backends, BIOS vs UEFI firmware choice, or VM lifecycle management. Invoke this skill BEFORE reading source code or launching Explore agents.
 
-**Workflow position:** Standalone workflow. VM management is separate from container lifecycle, but `charly fleet add vm:<name>` bridges into the shared InstallPlan + deploy-target machinery.
+**Workflow position:** Standalone workflow. VM management is separate from container lifecycle, but `charly deploy add vm:<name>` bridges into the shared InstallPlan + deploy-target machinery.
 
 Live-deploy verification: see [/charly-check:check](/recipes/check/check/) (the 11 Testing Standards) and [/charly-internals:disposable](/recipes/internals/disposable/).