The previous layout put AddressProbeStep at the top with the agent card
below as "Or install the agent on the host." Both sections read as
alternatives to the probe, which made the probe the primary action even
though the probe is inherently a Platform-API-oriented move (figure out
which API to connect to). A user committed to the agent path has no use
for it. The "Recommended" chip on the agent card did not fix this — the
structural lead won.
Move the agent card to the top of the Add landing with no divider above
it (it's the primary, not an alternative). Fold the probe + platform
grid into a single "Or connect a platform API directly" section below,
so the ordering matches the story: agent first, API as fallback for
hosts the agent can't cover.
Architecture pin in settingsArchitecture.test.ts updated to guard the
new ordering: agent card copy indexOf < API section indexOf < probe
indexOf. Explicitly asserts the old "Or install the agent on the host"
divider is gone.
Flip the two sections so the agent card sits above the platform grid
and reads "Recommended" with a blue border. The platform grid is now
explicitly framed as "Or connect a platform API directly — for VMware,
TrueNAS, PMG, or a remote Proxmox you can't install the agent on."
The ordering matches what the agent actually delivers: on a Proxmox
host it mints the API token and auto-registers both PVE and PBS with
zero credentials paste (RunAll in internal/hostagent/proxmox_setup.go).
The platform grid is the right path when the target is an appliance
you can't install on or a remote machine. Visual weight now matches
friction.
Architecture pin extended to assert the section ordering so a future
edit doesn't silently swap them back.
On a PVE or PBS host, the agent mints its own API token and registers
the node via RunAll (internal/hostagent/proxmox_setup.go + agent.go
:1295–1340). That is the fastest path to a working Proxmox connection
— no address paste, no credentials. Previous copy framed the agent
purely as "host metrics you add on top," which hid the shortcut and
steered Proxmox users into pasting credentials they did not need.
Reframe the two sections:
- "Or connect a remote platform API" — five tiles for when Pulse lives
elsewhere from the target (PMG / VMware / TrueNAS have no host-side
agent path, and remote Proxmox reaches the tile from a different box).
- "Or install the agent on the host" — leads with "On a Proxmox host,
this is the fastest path," then keeps the host-metrics pitch for
bare-metal Linux / Unraid / FreeBSD / Docker / Kubernetes.
Architecture pins extended to guard the Proxmox auto-register copy.
The flat catalog put Install Pulse Agent beside Proxmox / VMware /
TrueNAS as a peer. A user arriving to connect Proxmox picks Proxmox
instantly and never learns the agent also adds CPU temperature, disk
SMART, systemd services, and Docker/Kubernetes auto-detect on the host
itself.
Split the landing into two sections:
- "Or pick a platform to connect" — five peer tiles for PVE / PBS /
PMG / VMware / TrueNAS. These are management-API integrations and
belong together.
- "Or install a host-level agent" — a distinct full-width card with a
"Runs on a host" chip. Copy names the telemetry the agent adds and
says explicitly that it layers *in addition to* a platform connection
above, not instead of one.
The agent is a different kind of integration from the platform APIs.
Framing it as a peer hid its value; framing it as an adjunct teaches
it.
