a VM bed's nested kind:local child cannot deploy: bedAdd rewrites <root>.<child> to <root>/<child> #127

Finding

A VM bed with a nested kind:local child cannot deploy that child. The bed fails at the child's deploy add step, before any check runs:

$ charly check run check-containerd-vm
[deploy-add]                          PASS after 13.643s
[deploy-check-containerd-vm-member]   FAIL after 4.746s: exit 1: charly subcommand exited 1

$ cat .check/check-containerd-vm/2026.295.1137/deploy-check-containerd-vm-member.log
charly: error: command "deploy": charly deploy add: no <ref> and charly.yml has no entry for "check-containerd-vm/check-containerd-vm-member"
charly subcommand exited 1

The same resolution fails directly with the same string:

$ charly deploy add 'check-containerd-vm/check-containerd-vm-member'
charly: error: command "deploy": charly deploy add: no <ref> and charly.yml has no entry for "check-containerd-vm/check-containerd-vm-member"
rc=1

RCA

• Expected: the VM arm deploys the root, then pre-order deploys each d.LocalChildKeys entry as the dotted path <root>.<child> (check-containerd-vm.check-containerd-vm-member), which the loader resolves as the in-substrate member.
• Actual: the path handed to deploy add is <root>/<child> (a SLASH), which is a namespace-qualified deploy key, not a project entry. The resolver therefore sees node == nil and reports no entry.
• Mechanism (source):
  • candy/plugin-check/bed_run.go (VM arm): for _, childKey := range d.LocalChildKeys { step("deploy-"+childKey, bedAdd([]string{name + "." + childKey}, d.ImageTag)...) }
  • bedAdd calls deployKeyForBed(args[0]) for every non-remote ref.
  • deployKeyForBed splits at the FIRST dot and returns spec.DeployKey(ns, rest), i.e. <ns>/<name> — correct for a namespaced roster address (<ns>.<bed>.<child> → <ns>/<bed>.<child>), wrong for a non-namespaced bed's nested child (<bed>.<child> → <bed>/<child>).
  • plugin-fleet's node_resolve.go:82 then emits the error above because no node exists at that path.
• Missed control: bed_run_deploykey_test.go covers a namespaced nested child (openclaw.check-openclaw-pod.child) and a local bed with no child (check-mise-ubuntu-2604), but never a local bed WITH a nested child (check-containerd-vm.check-containerd-vm-member). The untested combination is the broken one, and no test asserts the child-deploy argv at all.
• Blast radius: every non-namespaced bed with an in-substrate kind:local child. The VM arm's d.LocalChildKeys loop and the kubevirt arm's d.ChildKeys loop share bedAdd, so both are affected. Measured on opencharly/layer-containerd's only VM bed (check-containerd-vm), whose root and child are both local/non-namespaced. The same bed passed on 2026-10-16 (PR fix(check): allowlist the dev/worktree binary notice #4 evidence) with an older charly binary; the call site is present in plugin-check from v0.2026287.1745 and the binary under test is 2026.293.1809 with plugin-check v0.2026293.1223 (go version -m).
• Root fix: convert the ROOT only, then append the child — bedAdd([]string{deployKeyForBed(name) + "." + childKey}, ...) — or pass the pre-resolved deploy key to bedAdd separately so a child path is never re-split. Add the missing test case (local bed + nested child) and assert the resulting argv, not only the helper's return value. plugin-check#100 (the VM [config] leg of the same helper) is the sibling defect, not the same call site.

Why this is filed here

The fix is in this repo's runner, not in the consuming candy repo: opencharly/layer-containerd#5 is a layer fix whose R10 gate is this bed, and the bed cannot reach its check. Filed from that leg; it blocks that PR's gate. Related: plugin-check#100, plugin-check#122 (this run's cleanup DID destroy the VM, so #122 was not hit).

• Bed: check-containerd-vm in opencharly/layer-containerd at a09b6d5 (control tree whose only difference from the fix tree is one candy run: step).
• Evidence: .check/check-containerd-vm/2026.295.1137/ (summary.yml, deploy-check-containerd-vm-member.log, runner.stderr.log).

Agent: containerd-crabbox-program/w13 · session 8b1c01cf-7f79-4a75-bff8-240415a06208
Assisted-by: Claude Code deepseek-v4.1-flash:cloud (analysed on a live system)