FM-941 — Proxmox page

[Andreas-Froyland]

Epic: #122 · Depends on: FM-901, FM-915

Context

Proxmox accounts/discovery/guests are only reachable via CLI and small panels.

Goal

A Proxmox page: accounts with trust state (pinned / changed fingerprint showing both values), nodes with capacity, storage, templates, guests, recent tasks, and an 'open in PVE' handoff.

Architecture reference

FM-600–603.

Dependencies

FM-901, FM-915

Research required

None.

Acceptance criteria

• Changed-fingerprint state blocks actions until re-confirmed

Non-goals

• A hypervisor console

Tests

Component tests; e2e observe→confirm.

[Andreas-Froyland]

Implementation approach (Claude)

UI-only, over the existing Proxmox API (FM-600–603, FM-915). No backend changes.

• /proxmox page (apps/web/src/pages/proxmox/):
  • Accounts: host, token id, and trust state:
    • unconfirmed: nothing pinned yet.
    • pinned: shows the pinned fingerprint.
    • changed: discovery answered proxmox_fingerprint_mismatch. The page observes the certificate and shows pinned vs observed side by side.
  • Re-pin: observe → an explicit "I verified this fingerprint out of band" acknowledgement → confirm (the same API as the Add dialog). Every command has "Copy as fleetctl".
  • Nodes: status and FM-915 capacity (CPU and memory bars, per-node storage usage).
  • Storage: storage resources joined with node storage capacity.
  • Templates: qemu-template resources.
  • Guests: status, node, guest agent, and association candidates linking to the machine page. Lifecycle actions (start/shutdown/reboot/stop) are confirmed first and run as durable operations. They use the account-level proxmox.operate authorization, so no machine is needed. Reviewed destructive operations stay on the machine Guest tab, which already implements review→token→run.
• Changed fingerprint blocks actions: for an unconfirmed or changed account, every guest action and the discovery-backed tabs are disabled, with an explanation, until the fingerprint is re-confirmed. The controller refuses those calls anyway; the UI doesn't offer them.
• Open in PVE: a link to the account's own web UI (and the guest/node selection in PVE's URL state). It is a handoff only; there's no console (non-goal).
• Recent tasks: the API has no PVE task-list endpoint, so this is shown as a documented gap rather than invented.
• Tests: unit tests for trust state, capacity, and joins; component tests; and an e2e observe → confirm re-pin against the stubbed API client that asserts actions are blocked until re-confirmed.