a VM bed's [config] phase still fails with the deployKeyForBed fix applied — the pod leg is fixed, the VM leg is not #100

STATUS — filed from opencharly/plugin-check#92, which the review correctly required to be a real issue rather than a sentence in a PR body.

What was measured

PR #92 fixed the namespaced-bed addressing bug: a bed is addressed <ns>.<name> by a roster but its deploy is keyed <ns>/<name> (spec.DeployKey), and charly config/charly start take the deploy key. The fix adds deployKeyForBed (reusing spec.DeployKey, never a hand-rolled split) and calls it for the config/start argv.

It works on the pod path and the evidence says so: charly config openclaw/check-openclaw-pod → exit 0, and the bed's own [config] phase PASS after 2m19.12s.

But re-run against a VM bed with the same fixed binary, its [config] phase still FAILS, after 1m42.03s.

[config]           PASS after 2m19.12s      # pod bed, fixed binary
[config]           FAIL after 1m42.03s      # VM bed, same fixed binary

Why that is a separate defect and not a second symptom

The pod leg and the VM leg reach the deploy differently, and the fix was written for the argv of charly config/charly start as the pod path invokes them. A VM bed's config phase resolves through its own chain, so the same roster-address/deploy-key confusion can survive there in a second place — and the fix's own claim ("reusing spec.DeployKey, never a hand-rolled split") is exactly the claim that one more unrepaired split would falsify.

Not established: which conversion the VM leg performs, and whether it is the same DeployKey question or a different one that merely fails at the same phase. That is the RCA this row owes, and guessing at it from a single timing is how the first wrong conclusion in this session was reached.

Relationship to plugin-check#96

This is the second of the two defects the review of #92 required to be filed. The first — the live-probe naming defect that reports a running namespaced container as "is not running" (harness_loop.go:962 vs :990 vs spec.ContainerName) — is already filed as opencharly/plugin-check#96, with its fix open as #97. It was filed before that review and the review could not see it; both are now named, and #92's ## Filed issues section lists them.

Agent: org-triage-2026-10-09
Assisted-by: dsh deepseek-v4.1-flash (analysed on a live system)