Contract-Neutral: Customer-facing punctuation cleanup only; no API, lifecycle, policy, or subsystem behavior changed. The owning frontend copy contract and lint enforcement are updated.
The shell fetched `/api/state` on every sign-in for two reasons: to learn
whether the session was authenticated, and to have something to render
before the socket connected. On a real estate that is 96% resources, and
the fetch sat on the critical path ahead of the websocket, which could not
begin connecting until it returned.
Neither reason survives. The session probe is now `/api/state/summary`,
which passes the same auth and monitoring-read scope checks and returns a
few hundred bytes. Navigation resolves from the platform admission facet.
Nothing else in the shell read the payload: `state()` had exactly three
consumers, two of them navigation and one an alert-count badge that the
socket supplies.
`/api/state` itself is untouched. It is the recovery path for a snapshot
too large for a websocket frame, which is precisely what the largest
estates need, so shrinking the endpoint would have removed the escape
hatch for the installs that depend on it most.
The seeded bootstrap state is gone rather than left empty. Keeping it
would have been actively unsafe: `runtimeStateResolved()` meant "a payload
arrived", so a bootstrap that no longer carried resources would still read
as resolved and navigation would classify an empty estate, hiding every
platform tab. Resolution is now websocket-backed, and an empty estate is
answered by the facet admitting nothing, which is a resolved answer rather
than an absent one.
Verified against two backends built from this change: a populated estate
resolves all six tabs, lands on the Proxmox overview and renders every
platform page, and an estate with zero resources shows no platform tabs in
the navigation landmark and lands on the infrastructure settings page.
Both issue one summary probe and zero `/api/state` requests.
Known regression: the alert-count badge is empty for the sub-second window
before the socket delivers alerts, where the bootstrap payload used to
supply it. The alerts store is not socket-synced, so reading the badge
from it would have traded a brief empty count for a lastingly stale one.
Tests that pinned the old mechanism were rewritten to their subjects: the
SSO and proxy-auth cases keep their auth assertions, and the empty-estate
distinction now asserts the facet admitting nothing rather than a
full-state payload arriving.
Contracts: performance-and-scalability records that the bootstrap is
estate-independent and that `/api/state` stays the recovery path rather
than a bootstrap surface; cloud-paid records the tenant probe.
The shell read the admission facet once at sign-in, which left two ways
for navigation to be wrong.
Switching organization was the serious one, and it was a defect in the
change that introduced the facet. The switch clears bootstrap state but
left admission untouched, so between the switch and the arrival of the new
tenant's runtime state the shell would render the outgoing tenant's
platform tabs. Admission is now cleared synchronously on the switch,
before anything can render from it, and refetched for the new tenant.
The second is a reconnect: an estate can gain or lose a platform while the
socket is down, so admission is refetched when the socket comes back. That
was verified by stopping the backend mid-session and restarting it, not by
toggling the browser offline, which leaves an established socket open and
silently proves nothing.
No polling is introduced. Live runtime state stays authoritative once it
arrives and tracks the estate itself, so a steady-state session makes no
further admission requests; that was measured rather than assumed.
I dropped a periodic backstop I had planned for sessions whose websocket is
blocked. The premise was wrong: such a session still receives runtime state
from the REST bootstrap, so navigation is already resolved and the timer
never fires. Verified against a socket-blocked session before removing it,
rather than shipping a session-long timer for a case that does not occur.
Contracts: cloud-paid gains the tenant-switch rule, and
performance-and-scalability records that admission refresh is event-driven
rather than polled.
The shell decided which platform pages exist by classifying every resource
in the runtime state payload, so navigation could not resolve until an
estate-sized payload had arrived. It now reads the platformAdmission facet
from the canonical resource contract, which answers the same question from
a one-resource request: 2KB against 314KB on the estate this was verified
on.
Precedence is deliberate. Live runtime state stays authoritative once it
arrives, because it tracks an estate that can gain a platform after the
facet was read; the facet only resolves navigation before that payload
exists. The two agree by construction, so the handover is not visible. A
server that does not report the facet keeps the previous behaviour rather
than hiding platforms the estate really has, and a partial facet payload is
rejected outright, since a missing flag would read as a hidden platform.
Verified against a backend built from the commit that publishes the facet:
navigation resolves with all six tabs, every platform page renders its own
rows, and the shipped facet equals the client classifier over the same
658-resource estate.
The architecture pin on the authenticated bootstrap gains the new loader.
Its invariant, that branding loads inside that bootstrap, is unchanged.
This does not yet free the state payload: it remains the steady-state
source for navigation, and other shell surfaces still read it.
Contracts: performance-and-scalability gains the rule that admission cost
must not scale with estate size; cloud-paid, ai-runtime and
storage-recovery gain the matching clauses for tenant scoping, hosted
surfaces and TrueNAS visibility.
The app shell decides which primary platform pages exist by classifying
every resource in the legacy full-state payload, which is why it has to
download that payload before it can render navigation. This publishes the
same answer as a `platformAdmission` facet on the canonical resource
aggregations, so admission has one definition instead of two that can
drift.
Counts cannot answer it, which is the whole reason this is a facet rather
than a client-side tally over `bySource`. A TrueNAS or Proxmox host
reports through the agent source and carries the "agent" platform scope,
so a count-based derivation admits the standalone page for an estate that
has no Pulse agent in it at all. Ownership is per-resource evidence, so it
is evaluated per resource here.
Verified against the live client classifier over real estates rather than
by inspection: the facet and the classifier agree on all six pages across
ten estates each for a 652-resource and a 216-resource estate, including
the cases that break a count-based derivation (Proxmox-only, TrueNAS-only,
vSphere-only and provider-owned-agents-only estates all correctly withhold
the standalone page, while a genuine Pulse agent admits it).
The tenant-fallback contract pin gains the new field. Its invariant, that
an empty tenant returns no resources rather than seeding from the raw
snapshot, is unchanged and still pinned; an empty estate admits nothing.
No caller reads the facet yet. Moving the shell onto it is a separate
change, gated by the same parity comparison.
Contracts: unified-resources and api-contracts gain the facet and its
derivation rule; agent-lifecycle and storage-recovery gain the ownership
clause, since an agent-typed host owned by a provider must not admit the
standalone page.
Contract-Neutral: Patrol autonomy behavior is documented in its primary ai-runtime and shared api-contracts contracts plus the relevant agent-lifecycle boundary; storage-recovery only has a broad internal/api extension reference and does not own this wire contract
checkZFSPoolHealth only runs while storage.ZFSPool is attached, so its
clear paths never fire once the attachment goes away and previously raised
zfs-pool-state, zfs-pool-errors, and zfs-device alerts linger until the
multi-day stale cleanup. Clear them on the spot when a storage is checked
without a pool. This is the recovery path for the shared storages that were
wrongly matched to a node-local pool before the matcher's type gate.
Refs #1731
matchZFSPoolForStorage's sole-pool fallback attached the node's only ZFS
pool to every storage the per-node endpoint returned, including NFS, CIFS,
PBS, and RBD entries that can never be backed by a local pool. One failing
device then raised a duplicate ZFS device alert per shared storage. Gate
the matcher on isInherentlySharedStorageType so remote-backed storages are
never matched, while dir-type storages keep the single-pool fallback.
Refs #1731
