/api/diagnostics is readable with settings:read and lists the whole token
inventory: every token's ID, name, timestamps, key hint and which agents
use it, across organizations. A token bound to one organization could
read the other organizations' credential metadata, which the token
management endpoints already refuse to show it.
The diagnostics result is computed once per organization scope and cached
for every caller, so the filter runs after the cache: an API-token caller
that is not instance-wide gets an API token section rebuilt over the
tokens callerTokenMayManage allows, with counts, notes and agent usage
computed over that view. Instance-wide tokens and browser sessions get the
full section, and the cache itself still holds the full result.
Tests cover the builder (tokens, counts, usage) and the handler on the
cached path, including that a scoped caller served from the cache does
not change what the next caller sees. Each filter fails when removed.
Contract-Neutral: Behavioural fix that applies the token visibility rule to diagnostics; no new API surface or contract.
Use the existing target-free Monitor fixture for diagnostics uptime and scheduler state; only the test's direct PVE/PBS probes contact its loopback server. Retain the initial nil-runtime failure without weakening production diagnostics or trust assertions.
Contract-Neutral: Tests only; supply the existing required diagnostics runtime without changing production source or diagnostic contracts.
Change-source: pulse-maintainer
Distinguish cancelled or timed-out probes from certificate faults before classifying error text. Replace verification-bypass advice with endpoint, chain and independently verified fingerprint checks across PVE and PBS diagnostics, including scheduler errors and support JSON.
Exercise real loopback trust refusal and operator-supplied pin recovery without changing stored trust, credentials or scheduler authority.
Contract-Neutral: Restore existing TLS/timeout diagnosis and safe recovery guidance; errorKind/schema, saved trust enforcement/settings, agent lifecycle and scheduler/recovery authority remain unchanged.
Change-source: pulse-maintainer
The required API shard failed because its healthy filesystem fixture omitted VM config. Supply a verified unlocked config instead of bypassing the guard, and cover backup/snapshot locks, absent or malformed config, permission refusals and locks appearing in flight through the real diagnostic client.
Contract-Neutral: Diagnostic fixtures and connected safety assertions only; production guest admission, APIs and polling behavior are unchanged.
Change-source: pulse-maintainer
Manifest-backed MCP tools, prompts, and resources with surface affordance contracts; agent capability manifest and governance projection; API contract tests and capability route projection; operations-loop and intelligence-funnel telemetry; release-control subsystem documentation, registry, and tooling; licensing and configuration.
Forward-port of the release/5.1 fix (9ac7df976). buildAlertsDiagnostic
previously emitted only cooldown/grouping flags, so triaging support
cases like #1341 where a user suspects an override key mismatch
required asking them to paste alerts config from inside their
container. Add an Overrides slice that names each persisted key with
its thresholds and disabled flags. Sanitize mode in the frontend
redacts the keys to override-N while keeping thresholds visible.
The /api/diagnostics handler builds its own test client per PVE node
to run a live connectivity probe. The PBS branch already passed
node.Fingerprint into the test client config, but the PVE branch did
not. With VerifySSL=true and a self-signed Proxmox cert (the standard
configuration), tlsutil.CreateHTTPClientWithTimeout falls into
default-secure mode and validates against the system CA chain, which
fails the handshake even when the actual poller — which DOES pass
the fingerprint — is connecting fine.
The result was that /api/diagnostics reported delly + pi as
"Failed to connect to Proxmox API" while /api/resources was happily
ingesting all 27 workloads from the same hosts. Mirror the PBS
branch by passing node.Fingerprint into the PVE testCfg so the
diagnostic probe uses the same TLS verification path as the runtime
poller.
Add a regression test that spins up an httptest TLS server, captures
its leaf cert SHA-256, configures a PVE instance with VerifySSL=true
and that fingerprint, and asserts computeDiagnostics reports
Connected=true. The pre-fix code fails this with a "tls: bad
certificate" handshake error.
rcourtman