wendy-device-ops

name	wendy-device-ops
description	Use when a developer or coding agent needs Wendy CLI-native device operations: discover devices, set defaults, inspect device version/system/hardware/WiFi state, update the agent, or gather evidence before SSH/debugging.

Wendy Device Ops Workflow

Use this for device operations that are not app build/run lifecycle. Prefer CLI-native, non-interactive commands before SSH.

Discover and select a device

Bound discovery so agents do not hang:

wendy discover --json --type all --timeout 5s
wendy discover --json --type usb --timeout 5s
wendy discover --json --type lan --timeout 5s

Use explicit hostnames when possible:

wendy device set-default <hostname>
wendy device get-default
wendy device unset-default

Passing the hostname to set-default avoids the interactive picker. Use --device <hostname> on later commands when you do not want to depend on local default state.

Inspect device state

Local CLI info:

wendy --json info

Target device info and platform facts:

wendy --json device info --device <hostname>
wendy --json device info --check-updates --device <hostname>

Hardware capabilities:

wendy --json device hardware list --device <hostname>
wendy --json device hardware list --category gpu --device <hostname>
wendy --json device hardware list --category camera --device <hostname>
wendy --json device hardware list --category audio --device <hostname>

Use the output to decide entitlements before guessing. For example, check device hardware list --category camera before adding camera-specific assumptions to an app.

WiFi operations

Read-only checks:

wendy --json device wifi status --device <hostname>
wendy --json device wifi list --device <hostname>

Mutating commands:

wendy device wifi connect --ssid "<ssid>" --password "<password>" --device <hostname>
wendy device wifi disconnect --device <hostname>
wendy device wifi forget --ssid "<ssid>" --device <hostname>
wendy device wifi rank --ssid "<ssid>" --priority 10 --device <hostname>
wendy device wifi rank --order "Home,Office,Cafe" --device <hostname>

Do not echo or store WiFi passwords in issues, PRs, reusable docs, or final summaries. If a password was passed on the command line, avoid copying the full command into shared output.

Agent update

Only update the agent when the user asks, when the device is clearly behind the CLI, or when a fix requires a newer agent. Prefer checking first:

wendy --json device version --check-updates --device <hostname>

Stable update:

wendy --json device update --device <hostname>

Nightly or local binary:

wendy --json device update --nightly --device <hostname>
wendy --json device update --binary ./path/to/wendy-agent --device <hostname>

SSH fallback

If CLI-native inspection cannot answer the question, WendyOS devices may temporarily allow:

ssh root@<hostname>

Use SSH primarily for read-only evidence collection and WendyOS issue filing. On the device, use containerd/nerdctl, not Docker:

cat /etc/wendyos/device-type 2>/dev/null || true
cat /etc/os-release 2>/dev/null || true
systemctl status wendy-agent --no-pager
journalctl -u wendy-agent -n 200 --no-pager
sudo nerdctl -n default ps -a
sudo nerdctl -n default logs <container>

Prefer changing app containers, wendy.json, or repo code over changing bare-metal device settings. If a direct device change is necessary, make it minimal and document it.

Routing

• Use wendy-app-lifecycle for build, run, logs, app start/stop/remove, and volumes.
• Use wendy-device-debug when the root cause spans CLI, agent, WendyOS image state, containerd, or app behavior.
• Use wendy-mcp-setup when the user wants AI tools to access Wendy device operations through MCP.