First slice of the device-commands.* protocol from
fleet/requests_over_nats.md. Lands `Verb::Ping` plus the harness that
proves it works against a real in-cluster agent.
Wire types (`harmony-reconciler-contracts::commands`):
- `Verb::Ping`, `CommandRequest`, `PingReply`, `ErrorReply`/`ErrorKind`
- `device_command_subject` / `device_command_subscription` helpers
- `X-Harmony-*` header constants
Agent:
- `command_server.rs` subscribes on `device-commands.<id>.>` and
dispatches verbs; ping handler replies with `PingReply`
- New `[agent].runtime_enabled` config flag (default true). When
false, podman init + reconciler loop are skipped so the agent can
run as a Pod on containerd-only k3d nodes; command server +
heartbeat still run
- `Dockerfile`: canonical multi-stage build for production registries
Operator:
- `commands::FleetCommandsClient` with typed `CommandError`
(`DeviceOffline` via `no_responders`, `Timeout`, `BadReply`, `Nats`)
E2E harness (`harmony-fleet-e2e`):
- Library crate + integration test. `Stack::bring_up` provisions a
fresh `e2e-<uuid8>` namespace in a shared `fleet-e2e` k3d cluster,
deploys NATS (UserPass auth, JetStream on) + the agent Pod, returns
a connected admin NATS client, and tears the namespace down on Drop
- v1 ships `AuthMode::UserPass` only; the `Callout` variant is
reserved on the public API for the follow-up PR that adds the mock
OIDC fixture + NatsAuthCalloutScore deployment
- Operator pod deployment is also follow-up — for ping the test
process drives `FleetCommandsClient` directly against the cluster's
NATS NodePort
- `HARMONY_FLEET_E2E=1` gates the integration test so default
`cargo test --workspace` runs don't depend on k3d/podman
- Image build + sideload mirrors the `fleet_auth_callout` pattern:
host `cargo build --release` → single-stage Dockerfile → `podman
build` → `k3d image import`. ~12s warm bring-up, ~80s cold
Jean-Gabriel Gill-Couture
d013246a68