mirror of
https://github.com/rcourtman/Pulse.git
synced 2026-10-27 14:07:31 +00:00
rcourtman
02e4ce2bcc
`WorkloadsSurface` built its own workloads state when no `state` prop
arrived, and its props type extended every `useWorkloadsState` option.
Both production mounts (the Proxmox and vSphere overviews) already build
that state themselves, since it also drives their one `WorkloadsFilter`,
and pass it in. So the fallback only ran in tests, and the mounts passed
`vms`, `containers`, `nodes`, `useWorkloads` (and on Proxmox the
app-container exclusion) that the surface ignored once it had a state.
### What changed
- The surface requires `state` and accepts only `forcedPlatform`,
`forcedViewMode`, the empty-state copy and `tableTitle`. The hook's
options type is now `WorkloadsStateOptions`, so it no longer shares a
name with the surface's props.
- Both pages drop the ignored mount props. The hook-call options
(`excludedWorkloadTypes`, `showNestedExcludedWorkloads`, ...) stay where
they act.
- `WorkloadsSurface.k8s` and `.performance.contract` tests build state
through a `PageOwnedWorkloadsSurface` harness, as the pages do.
Stub-state renders just lose the dead props.
- New pins: the Proxmox page contract test asserts the exact props its
mount passes; the overview guardrails check that each surface repeats
the platform and view scope its page gave the state, and that the
surface imports only the state's type (AST, so formatting and aliasing
cannot get past it).
- `ProxmoxBackupsTable.test.tsx` loses its two pins on the removed JSX
attributes; the hook-call pins that protect backup coverage stay.
- Contract prose in performance-and-scalability, storage-recovery,
unified-resources and frontend-primitives.
### Bundle budget
Once the surface imports only the state's type, Rollup names the chunk
the Proxmox and vSphere pages share after its last module (`rollup`
`getFallbackChunkName` takes `orderedModules[last]`), which is now
`useWorkloadsState`, and the bundle check reported the tracked
`WorkloadsSurface` key as `MISSING`. It is the same code at the same
size, so `.bundlesize.json` renames the key and leaves the baseline and
limit alone. I did not pin the name through `manualChunks`: that would
change chunk composition for a naming concern.
### Evidence (pulse-dev, origin/main 9a32396fe2 vs this change)
- Unminified builds with the renamed chunk mapped back: the shared chunk
is identical except three lines (two minifier import-alias lines and
`props.state ?? useWorkloadsState(props)` -> `props.state`);
`Proxmox.js` and `Vmware.js` shrink by exactly the removed JSX props
(183 and 80 bytes); every other differing chunk differs in one import
line of minifier aliases, from a reordered export list of the same 608
names.
- Bundle check passes on both trees: 57.94 kB before, 57.63 kB after,
limit 70.23 kB.
- Browser pass of both overviews at 1440 and 390 wide against the mock
estate: 90 of 90 readings identical, in two repeated pairs (row and
group counts, titles, headers, filtered-empty copy, Back to top, inline
drawer, one toolbar outside the surface). My first probe could not open
the phone drawer on either build (a backup-status button overlaps the
chevron); the second one dispatches the click and covers it.
- `tsc` clean (pulse-dev, and in the pre-push hook on the merged tree).
The commit's pre-commit lint chain passed; the pre-push `eslint` was
cancelled by the local workload gate, so CI's Frontend job is the lint
of record for the merged tree. The pin tests (9 files) pass on both
trees. A full sweep of the Workloads, Proxmox, vSphere, platform-page,
shared, utils, hooks and Storage suites showed only load timeouts at
pulse-dev load ~120; every failing file passes alone on both trees (23
files, 718 tests).
- Negative controls: the new Proxmox test fails against the unchanged
page (extra props), and the new guardrail fails against the unchanged
tree and against the fallback surface restored over this change.
- Second opinion (Sol, read-only) in four rounds; each round's findings
are fixed: a spelling-based ratchet replaced by the AST check,
overclaiming contract sentences narrowed, and the `MISSING` remedy
limited to a confirmed rename.
### Notes
- `useWorkloadsState` itself never reads `vms` or `containers`, and both
pages pass `nodes: []` and `useWorkloads: true`. Main's `retains
separate supplied tuples sharing a native ID` test does pass real
`nodes`, so removing those options needs a deliberate decision; that is
a separate follow-up.
- Observed, not changed here: in the phone-width probe, a tap at the
centre of a Proxmox row's expand chevron was intercepted by the 44px
backup-status button next to it (Playwright reported that button as
intercepting pointer events), on both builds.
Pulse documentation
Start here for installation, platform setup, security, operations, and Pulse Intelligence. Commands, configuration keys, image names, API fields, and product identifiers remain untranslated in localized guides.
Start here
- Install Pulse — signed Proxmox/Linux installation, Docker, Docker Compose, Kubernetes, and first-run setup.
- Production deployment and security — least-privilege Proxmox setup, root-agent boundaries, discovery, supply-chain verification, plan limits, scale evidence, and a rollout checklist.
- Upgrade from Pulse v5 — migration prerequisites, rollback, agent continuity, and post-upgrade checks.
- Releases and update channels: choosing Stable or Preview, beta and RC expectations, and how releases are tested and promoted.
- Configure Pulse — authentication, notifications, discovery, retention, and system settings.
- Deployment models — data locations, lifecycle, and differences between supported deployment paths.
- Troubleshooting and FAQ — common failures, diagnostics, and operator questions.
Localized getting started guides: Deutsch · Español
Platforms and agents
- Proxmox Backup Server
- Proxmox Mail Gateway
- Docker and Podman
- Kubernetes and Helm
- TrueNAS SCALE and CORE
- Unified Agent
- Agent security
- VM disk monitoring
- ZFS monitoring
- Temperature monitoring
VMware vSphere support is early access. Current builds expose dedicated vSphere inventory and recovery context, but operators should validate the integration against their own vCenter before production use.
Monitoring and operations
- Metrics history
- Recovery data
- Webhooks
- Automatic updates
- Centralized agent management (Pro)
- Operational trust model
- Current product screenshots
Pulse Intelligence
- Assistant, Patrol, and external-agent overview
- Patrol modes and safety
- Assistant safety model
- External agent HTTP and MCP substrate
Patrol watch-only analysis is available on Community with a local model or the operator's own provider. Investigation and governed fixes require the relevant Pulse Pro capabilities.
Security, privacy, and access
- Production deployment and security
- Security review scope
- Authentication and credential storage review packet
- Security guide
- Privacy and telemetry disclosure
- OIDC and SSO
- Proxy authentication
- Role-based access control (Pro)
- Audit logging (Pro)
- Reverse proxy configuration
- Code-signing policy
Plans and managed access
- Community, Relay, and Pro capabilities
- Relay and Pulse Mobile handoff
- Multi-tenant organizations (Enterprise/custom)
- Provider-hosted MSP operations (request-assisted)
Pulse Cloud is not generally available. Ordinary self-hosted Pulse remains the primary installation path; MSP and Enterprise access are explicit commercial paths rather than defaults in self-hosted setup.
Development and reference
Detailed design notes and dated migration specifications may remain in this directory for maintainers, but they are not operator setup guides unless they are linked from the sections above.
Previous versions and migrations
- Upgrade from v4 to v5
- Retired unified-navigation migration — historical context only; current Pulse uses platform-shaped navigation.
- Move a Pulse installation
Found a bug? Use the issue forms. For setup questions, use GitHub Discussions.