Audited the customer-facing docs against the code: about 5,200 concrete
claims (env vars, endpoints, flags, defaults, ports, UI labels), plus every
environment variable the code reads. Each discrepancy was re-verified
against the source before editing, and every edit was reviewed again.
What users would have hit following the old text:
- UI paths and labels that no longer exist (Settings > Relay, Platform
connections, Access Control, SSO Providers, Create Organization) and
Patrol mode names (now Ask first, Safe auto-fix, Autopilot).
- Wrong values and behaviour: LOG_MAX_AGE=0 does not disable cleanup,
Patrol evidence budget is 10 calls and 12 turns, ALLOW_UNPROTECTED_EXPORT
covers private networks too, PULSE_AUDIT_ASYNC defaults on.
- Agent install: install.sh ignores PULSE_ENABLE_KUBERNETES and
PULSE_ENABLE_PROXMOX, rejects --disable-auto-update, and the token
fallback lives in the state directory.
- API: audit endpoints answer 402 on Community, onboarding QR is GET,
type=container is rejected, several routes need admin plus a scope.
- HTTP_REDIRECT_PORT was not documented anywhere.
Docs are mirrored under frontend-modern/public/docs, so each change is
applied to both copies. The tests that pinned the old wording (including
three that asserted claims the code contradicts) are updated alongside.
Contract-Neutral: Customer docs corrected to match shipped behaviour; no runtime, API or contract change.
When adaptive polling is enabled (ADAPTIVE_POLLING_ENABLED or system.json;
off by default, no UI), the scheduler picks PVE, PBS and PMG intervals
itself and never reads the per-platform ones. A healthy instance's
staleness score is near zero after every success, so its cadence stretches
toward AdaptivePollingMaxInterval (5 minutes by default). Resource
freshness was still derived from the per-platform intervals, with floors of
60s for Proxmox and 120s for PBS and PMG, so healthy rows read stale for
much of every cycle. A live stack with a fake PMG polled 3.5 to 4.3
minutes apart and the row sat degraded with telemetry_stale from two
minutes after each poll until the next one. The PVE node offline grace and
the node temperature carry window derive from the same cadence and lapsed
between polls too.
Monitor.resourcePollIntervals now judges all three sources by the
scheduler's own maximum interval, which bounds every interval it selects.
ResourceStaleThresholdsForConfig reads the same normalized bounds through
a normalizedSchedulerConfig shared with NewAdaptiveScheduler, so callers
without a monitor agree with the one that has it. The same live stack
stayed online for 14 minutes. Fixed-cadence behaviour is unchanged.
Per-instance planned intervals were not used: they are jittered and shrink
as a poll runs late, so a per-source threshold built on them would flap.
The contract note this replaces said freshness keeps deriving from the
per-platform intervals; the user doc now says what adaptive polling does to
freshness and offline detection. The cost is a longer node hold in
adaptive mode (10 minutes with the defaults). A valid /cluster/status
report that a member is offline still applies immediately.
Use one bounded, authenticated snapshot and local queries instead of secret-bearing argv and repeated requests. Preserve configuration precedence and rollback state, and judge successful polls rather than a universal queue-depth threshold. Exercise copied commands with HTTP, transport, schema and credential controls.
Contract-Neutral: Documentation and copied-command tests only; scheduler runtime and API contracts are unchanged.
Change-source: pulse-maintainer
Update docs to reflect the simplified temperature monitoring architecture:
- Remove references to pulse-sensor-proxy throughout
- Update TEMPERATURE_MONITORING.md to focus on unified agent approach
- Update CONFIGURATION.md, DEPLOYMENT_MODELS.md, FAQ.md
- Remove SECURITY_CHANGELOG.md (proxy-specific security notes)
- Clarify current recommended setup in various guides
- Major updates to README.md and docs/README.md for Pulse v5
- Added technical deep-dives for Pulse Pro (docs/PULSE_PRO.md) and AI Patrol (docs/AI.md)
- Updated Prometheus metrics documentation and Helm schema for metrics separation
- Refreshed security, installation, and deployment documentation for unified agent models
- Cleaned up legacy summary files
Add contextual help icons throughout the UI to improve feature
discoverability. Users can click (?) icons to see explanations
with examples for settings they might not understand.
- HelpIcon component with click-to-open popover
- Centralized help content registry in /content/help/
- FeatureTip component for dismissible contextual tips
- Help added to: alert delay, AI endpoints, update channel
Adds IncludeAllDeployments option to show all deployments, not just
problem ones (where replicas don't match desired). This provides parity
with the existing --kube-include-all-pods flag.
- Add IncludeAllDeployments to kubernetesagent.Config
- Add --kube-include-all-deployments flag and PULSE_KUBE_INCLUDE_ALL_DEPLOYMENTS env var
- Update collectDeployments to respect the new flag
- Add test for IncludeAllDeployments functionality
- Update UNIFIED_AGENT.md documentation
Addresses feedback from PR #855
The previous diagrams were too complex and overwhelming. Simplified
all diagrams to show core concepts clearly:
- Adaptive polling: reduced to basic scheduler→queue→workers flow
- Temperature proxy: simplified to 3-box trust boundary view
- Sensor proxy sequence: simplified to essential request flow
- Webhook pipeline: reduced to template→send→retry flow
- Script library: simplified to code→test→bundle→dist flow
Fixed parsing error in temperature proxy diagram (parentheses in
edge label causing render failure).
Diagrams should clarify architecture, not recreate implementation.
Replace internal development phase reference with clear description
of what the adaptive polling scheduler does. 'Phase 2' is internal
jargon that provides no value to users.
Task 8 of 10 complete. Exposes read-only scheduler health data including:
- Queue depth and distribution by instance type
- Dead-letter queue inspection (top 25 tasks with error details)
- Circuit breaker states (instance-level)
- Staleness scores per instance
New API endpoint:
GET /api/monitoring/scheduler/health (requires authentication)
New snapshot methods:
- StalenessTracker.Snapshot() - exports all staleness data
- TaskQueue.Snapshot() - queue depth & per-type distribution
- TaskQueue.PeekAll() - dead-letter task inspection
- circuitBreaker.State() - exports state, failures, retryAt
- Monitor.SchedulerHealth() - aggregates all health data
Documentation updated with API spec, field descriptions, and usage examples.
rcourtman