Codex Agent
bc059fa49d
The CLI was emitting workspace.build/debug.download with action=evidence for "<pod>:workspace build evidence <jobId>" and "<pod>:debug-probe download evidence <jobId>". Cloud-api accepted the sub-action form, but the device-pod executor mapped it to device-host-cli argv as "workspace build evidence" / "debug-probe download evidence" -- neither of which exists in the host CLI dispatcher; the host returned "unsupported command: --profile-json-b64 ..." and the evidence job was marked failed with blocker.code gateway_dispatch_failed. Per docs/reference/g14.md (v0.2 device-pod cloud-api architecture), "The evidence sub-action on workspace.evidence / debug.evidence is a first-class intent, not a workspace.build sub-action." The executor's deviceHostArgs already produces the correct argv for the first-class intent, so the fix lives in the CLI selector parser: when operation === "build" and rest[1] === "evidence", emit intent=workspace.evidence with kind=build and the explicit jobId; the same shape for operation === "download" -> debug.evidence with kind=download. Non-evidence sub-actions (start, status, wait, output, cancel) are unchanged. Live verification on G14 against http://74.48.78.17:19667 (D601-F103-V2, profileHash sha256:0352cd14...): - before: device-host-cli argv = "workspace build evidence" -> gateway_dispatch_failed - after: device-host-cli argv = "workspace evidence build <jobId> ..." accepted by cloud-api with status=running, blocker=null - the executor argv proves the fix; the D601 Windows host F:\Work\ConStart\tools\device-host-cli.mjs is still a stale D601 ops-side copy and is tracked separately in #779 (out of scope for #801). Adds: - device-pod-cli.test.ts: evidence sub-action -> first-class intent - device-pod-cli.test.ts: build start / download start regression (non-evidence sub-actions keep workspace.build / debug.download) Out of scope: COM9 -> COM3 UART port drift on the Windows device pod host (separate issue from #801; no UART/profile port code touched).