Add rc.6 operator support pack and prerelease index pointers

Stages the doc-only subset of rc.6 packet prep work on top of
df7934936. Holds VERSION bump and the registry/contract governance
reconciliation back for a focused later pass since the IA revert
created broader subsystem-contract debt than the packet prep can
absorb.

- docs/releases/V6_RC6_OPERATOR_SUPPORT_PACK_DRAFT.md: new 300-line
  operator support brief mirroring the rc.5 pack with rc.6 themes:
  pre-release for testing framing, platform-shaped frontend revert
  explanation, vSphere as a first-class platform, Machines surface,
  TrueNAS native detail UX, FilterBar adoption, Patrol capacity-
  forecast and PDM bridge, free-first self-hosted posture, install.sh
  smoke gate. Carries the rc.5 free-first paid-continuity wording
  through unchanged so the operator-support-pack policy test holds.
- docs/releases/RELEASE_NOTES_v6_RC6_DRAFT.md,
  docs/releases/V6_CHANGELOG_RC6_DRAFT.md: fill in the SHA audit
  numbers (v6.0.0-rc.5..df7934936, 616 commits, 1379 files / 139185
  insertions / 67870 deletions). Add the licensing-continuity
  paragraph carrying the rc.5 Pulse Mobile pairing for handoff
  copy through unchanged so the discovered-packet policy test holds.
- docs/RELEASE_NOTES.md: link the rc.6 draft packet as current, push
  rc.5 to historical.
- docs/UPGRADE_v6.md: round out the prerelease packet pointer block
  with the rc.6 operator support pack path alongside the release
  notes and changelog already pointed at in df7934936.
- docs/releases/V6_PRERELEASE_RUNBOOK.md: add 6.0.0-rc.6 to the
  version-examples list and bump the RC_VERSION export shown in the
  RC release steps to rc.6.

Out of scope for this commit and intentionally held back until
governance reconciliation can land coherently:

- VERSION bump to 6.0.0-rc.6 (triggers deployment-installability
  shape-guard which cascades into registry/contract audits against
  72 dead-file references left over from the rc.6 IA revert).
- docs/release-control/v6/internal/status.json,
  docs/release-control/v6/internal/subsystems/registry.json, and the
  10 subsystem contract .md files that need post-IA-revert cleanup.
- scripts/release_control test fixture refreshes.
- The rc-to-ga-promotion-readiness-blocked record regen (gated on
  VERSION bump landing).

Working copies of the held-back files are preserved at
/tmp/rc6-prep-backup-2026-05-27/ with a MANIFEST.md describing each.
This commit is contained in:
rcourtman 2026-05-27 13:37:24 +01:00
parent ed8a9652b2
commit affc1c76ed
6 changed files with 409 additions and 24 deletions

View file

@ -16,7 +16,12 @@ For the historical shipped v6 `rc.1` packet, see:
- `docs/releases/V6_CHANGELOG_RC1.md`
- `docs/releases/V6_RC_OPERATOR_SUPPORT_PACK.md`
For the current in-repo v6 `rc.5` draft packet, see:
For the current in-repo v6 `rc.6` draft packet, see:
- `docs/releases/RELEASE_NOTES_v6_RC6_DRAFT.md`
- `docs/releases/V6_CHANGELOG_RC6_DRAFT.md`
- `docs/releases/V6_RC6_OPERATOR_SUPPORT_PACK_DRAFT.md`
For the historical in-repo v6 `rc.5` draft packet, see:
- `docs/releases/RELEASE_NOTES_v6_RC5_DRAFT.md`
- `docs/releases/V6_CHANGELOG_RC5_DRAFT.md`
- `docs/releases/V6_RC5_OPERATOR_SUPPORT_PACK_DRAFT.md`

View file

@ -11,6 +11,7 @@ For the current v6 prerelease packet, see:
- `docs/releases/RELEASE_NOTES_v6_RC6_DRAFT.md`
- `docs/releases/V6_CHANGELOG_RC6_DRAFT.md`
- `docs/releases/V6_RC6_OPERATOR_SUPPORT_PACK_DRAFT.md`
## Before You Upgrade

View file

@ -144,6 +144,12 @@ self-hosted Pro continuity holds with no caps, and the Pulse Pro value
copy was aligned to the free-first posture. The Pro upsell path remains
opt-in.
The licensing posture from `rc.5` carries through unchanged: Community,
Relay, and Pro include core monitoring included by default; Relay
remains secure remote access to the Pulse web UI, Pulse Mobile pairing for handoff,
push notifications, and 14-day history; Pro remains Relay plus AI
operations, automation, advanced admin features, and 90-day history.
### Install pipeline hardening
The release pipeline now ships `install.sh` as a GitHub Release asset,
@ -172,20 +178,21 @@ are fixed.
## Validation
This packet should be audited against the commit range from the
published `v6.0.0-rc.5` tag through the validation-risk commit:
This packet is audited against the commit range from the published
`v6.0.0-rc.5` tag through the validation-risk commit:
- `v6.0.0-rc.5`: `<populate at packet finalisation>`
- validation-risk commit: `<populate at packet finalisation>`
- range: `v6.0.0-rc.5..<validation-risk-sha>`
- `v6.0.0-rc.5`: `604a94d46e3be3687229e429aea282d3c3015fa4`
- validation-risk commit: `df793493683737c31961dd5b770fd98d37fa15d8`
- range: `v6.0.0-rc.5..df793493683737c31961dd5b770fd98d37fa15d8`
- commit count: `616`
- changed scope: `1379` files, `139185` insertions, `67870` deletions
Expected scope: roughly 600+ commits, with the bulk concentrated in
`frontend-modern/src` (information architecture revert, vSphere
surface, Machines detail UX), `internal/vmware` (new vSphere
collector and inventory), `internal/api` (recovery and resources
contract continuity), `internal/ai` (capacity-forecast, PDM bridge,
verification substrate), and `.github/workflows` (install.sh smoke
gate).
The bulk of the range is concentrated in `frontend-modern/src`
(information architecture revert, vSphere surface, Machines detail
UX), `internal/vmware` (vSphere collector and inventory work),
`internal/api` (recovery and resources contract continuity),
`internal/ai` (capacity-forecast, PDM bridge, verification
substrate), and `.github/workflows` (install.sh smoke gate).
## Retest Plan

View file

@ -34,16 +34,14 @@ hardening.
## Commit Coverage Audit
The changelog should be audited against every feature/runtime commit
in the exact code-backed release-validation range for the current
candidate:
The changelog is audited against every feature/runtime commit in the
exact code-backed release-validation range for the current candidate:
- `v6.0.0-rc.5`: `<populate at packet finalisation>`
- validation-risk commit: `<populate at packet finalisation>`
- range: `v6.0.0-rc.5..<validation-risk-sha>`
- expected commit count: 600+
- expected changed scope: 1300+ files, 130000+ insertions, 65000+
deletions
- `v6.0.0-rc.5`: `604a94d46e3be3687229e429aea282d3c3015fa4`
- validation-risk commit: `df793493683737c31961dd5b770fd98d37fa15d8`
- range: `v6.0.0-rc.5..df793493683737c31961dd5b770fd98d37fa15d8`
- commit count: `616`
- changed scope: `1379` files, `139185` insertions, `67870` deletions
Those commits are grouped in this changelog rather than listed one by
one. The range carries: the frontend information architecture revert
@ -192,6 +190,14 @@ Patrol gained:
A storage-growth-planner runway widget was prototyped and removed in
the same range; it is not present in `rc.6`.
### 7a. Licensing continuity from `rc.5`
The licensing posture from `rc.5` carries through unchanged: Community,
Relay, and Pro include core monitoring included by default; Relay
remains secure remote access to the Pulse web UI, Pulse Mobile pairing for handoff,
push notifications, and 14-day history; Pro remains Relay plus AI
operations, automation, advanced admin features, and 90-day history.
### 8. Self-hosted commercial posture: free-first
Self-hosted commercial framing moved to free-first:

View file

@ -63,7 +63,7 @@ artifacts, or to an explicitly verified paid container image, rather than the pu
## Versioning Rules
- v5 stable examples: `5.1.14`
- v6 prerelease examples: `6.0.0-rc.1`, `6.0.0-rc.2`, `6.0.0-rc.3`, `6.0.0-rc.4`, `6.0.0-rc.5`
- v6 prerelease examples: `6.0.0-rc.1`, `6.0.0-rc.2`, `6.0.0-rc.3`, `6.0.0-rc.4`, `6.0.0-rc.5`, `6.0.0-rc.6`
- v6 GA example: `6.0.0`
The workflow auto-marks `-rc.N`/`-alpha.N`/`-beta.N` as prerelease.
@ -93,7 +93,7 @@ The workflow auto-marks `-rc.N`/`-alpha.N`/`-beta.N` as prerelease.
1. Update version on `pulse/v6-release`:
```bash
export RC_VERSION="6.0.0-rc.5"
export RC_VERSION="6.0.0-rc.6"
git checkout pulse/v6-release
git pull --ff-only

View file

@ -0,0 +1,366 @@
# Pulse v6 RC6 Draft Operator Support Pack
_Draft only. Use this as the working support brief for the planned
`v6.0.0-rc.6` candidate until the final prerelease notes are published._
## Support Stance
- Pulse v5.1.32 remains the current stable line.
- Pulse v6 `rc.6` is an opt-in evaluation build, not the default
production recommendation. The framing is closer to "pre-release
for testing" than to "GA candidate"; the build is published on the
existing `rc` update channel because the prerelease update path is
RC-shaped (`internal/updates/version.go`,
`internal/config/config.go`), not because the RC is days from GA.
- `rc.6` should be described as the frontend-reset RC. The headline
change is that the unified `Infrastructure` / `Workloads` /
`Storage` / `Recovery` top-level pages that shipped across
`rc.1`-`rc.5` are reverted, and the frontend is platform-shaped
again (Proxmox, Docker, Kubernetes, TrueNAS, vSphere, Standalone,
plus Alerts, Patrol, and Settings). The unified resource model and
`/api/resources` contract remain on the backend; the platform-shaped
pages consume that contract and add platform-shaped presentation.
- Beyond the IA revert, `rc.6` ships vSphere as a first-class platform,
the Standalone-to-Machines surface evolution with native detail UX,
TrueNAS native detail rendering, Proxmox backup recovery coverage
and tab polish, FilterBar adoption with SavedViews, Patrol
capacity-forecast and reliability-finding additions, the free-first
self-hosted commercial posture, and `install.sh` release-pipeline
hardening.
- Self-hosted SSO is included with Community and higher tiers. Do not
describe SAML or multi-provider SSO as a Pro-only upgrade path for
this RC.
- Stable-channel installer resolution must stay on the latest stable
semver tag even if GitHub's floating latest-release redirect
currently points at an RC.
- Systems pinned to the historical `rc.2` update trust root should use
a manual reinstall or explicit trust migration for later prerelease
or GA builds.
## Short Answers
### Is `rc.6` the stable release?
No. The current stable release is v5.1.32. `rc.6` is still a v6
prerelease for controlled evaluation.
### Should production v5 users upgrade immediately?
No. The recommended RC posture is still staging, lab, or controlled
evaluation first.
### Why does the frontend look like v5 again?
That is the point of `rc.6`. Across `rc.1` through `rc.5`, operator
feedback on the unified `Infrastructure` / `Workloads` / `Storage` /
`Recovery` layout consistently preferred the platform-shaped
navigation v5 already had. `rc.6` reverts the frontend information
architecture to platform-shaped top-level pages while keeping the
unified resource model on the backend. Same backend, the navigation
shape v5 operators already know.
### What is the rollback target?
Use v5.1.32:
`./scripts/install.sh --version v5.1.32`
### Can `rc.2` systems auto-update directly to `rc.6`?
Do not promise unattended continuity from `rc.2` to `rc.6`. Hosts
pinned to the historical `rc.2` update trust root need a manual
reinstall or explicit trust-migration path for later prerelease or GA
builds.
### Will my `rc.1`-`rc.5` bookmarks still work in `rc.6`?
Bookmarks to the platform-shaped top-level routes (`/proxmox`,
`/docker`, `/kubernetes`, `/truenas`, `/vmware`, `/standalone`,
`/alerts`, `/patrol`, `/settings`) continue to resolve unchanged.
Bookmarks into the briefly-shipped unified routes (`/infrastructure`,
`/workloads`, `/storage`, `/recovery`) are retired and need to move to
the platform-shaped equivalents. The unified resource model and
`/api/resources` contract remain on the backend, so automation
targeting the API contract is unaffected.
### Does self-hosted v6 still cap monitored systems?
No for the current public self-hosted plans. Community, Relay, and Pro
include core monitoring included by default.
Current plan shorthand:
- Community:
core monitoring included, OIDC/SAML SSO with multi-provider support,
7-day history
- Relay:
core monitoring included, secure remote access to the Pulse web UI,
Pulse Mobile pairing for handoff, push notifications, and 14-day
history
- Pro:
Relay plus AI operations, automation, advanced admin features, and
90-day history
### What happens to existing paid Pulse Pro customers in v6?
Use this cohort breakdown:
- Legacy recurring monthly or annual subscribers from v5 or earlier who
were already active before the public v6 pricing cutover:
keep the current recurring price, with self-hosted monitoring and
child-resource volume not metered while the subscription remains
continuously active under the current v6 policy.
- Existing lifetime customers:
remain permanently valid, with self-hosted monitoring and child-
resource volume not metered under the current v6 policy.
- Legacy paid v5 licenses migrated into v6 outside the recurring
grandfathered path:
can still exchange into the v6 activation model without repurchasing.
- Former recurring subscribers who already canceled or later lapse:
any later return uses current public v6 pricing rather than resuming
the old grandfathered terms.
### What changed from `rc.5` that users should notice immediately?
- The frontend top-level navigation is platform-shaped again. The
unified `Infrastructure` / `Workloads` / `Storage` / `Recovery`
pages, their aggregate route aliases, and the orphaned summary
components and aggregate state hooks that fed them are removed.
Drawer shells are unified across Workloads, Docker, K8s, and host
detail drawers so platform pages share their detail surface. The
keyboard shortcuts moved to platform keys: `g p` Proxmox, `g d`
Docker, `g k` Kubernetes, `g n` TrueNAS, `g v` vSphere, `g s`
Standalone, `g a` Alerts, `g r` Patrol, `g t` Settings.
- vSphere is a first-class platform in `rc.6`, parallel to Proxmox,
Docker, Kubernetes, and TrueNAS. The surface ships VMs through the
shared workloads pipeline, network inventory, Hosts table with
version and uptime, cluster services, VM hardware config, VMware
Tools status, vCenter MoRef in the workload ID, snapshot trees, and
a vSphere placement card in the workload drawer.
- The surface previously labelled "Agents" and then "Standalone" is
now "Machines". The Machines table gained row identity context,
expansion affordance, IP / disk I/O / RAID / network / temperature
detail tooltips, an aggregate disk summary, SMART temperature
fallback, and machine discovery promoted into drawer tabs. Machines
is now restricted to Pulse Agent resources.
- TrueNAS gained native inline detail rendering across storage,
system, service, protection, and health rows. TrueNAS health alerts
surface on the overview and alert detail rows appear in the drawer.
- Proxmox backup tabs got click-to-sort across all three tabs, visual
density alignment with Storage and Ceph pages, a canonical
ProgressBar for metric bars, a workload-row backup-age display, and
a coverage view that surfaces which workloads have recent PBS
artifacts. The Replication tab is hidden when no replication signals
exist.
- FilterBar pattern (chips plus `+ Filter`) expanded into Alerts
history, the audit log filter form, the embedded workloads filter,
and Storage, with URL-backed filter state and SavedViews. Workloads
search and `statusMode` moved to URL params; the localStorage backup
for `viewMode` and `containerRuntime` was dropped. URL state is the
single source of truth.
- Patrol gained a capacity-forecast action template registry, forecast
proposals that attach onto a Patrol `RemediationPlan`, a reliability
finding that fires when an alert starts flapping, a PDM (Proxmox
Datacenter Manager) HTTP alert source and bridge, and a
verification-outcome and capability-postcondition substrate for
finding lifecycle.
- Self-hosted commercial framing moved to free-first. Trial start
route, trial signup control plane, trial activation callback, AI
quickstart surfaces, hosted AI quickstart runtime, monitored-system
handoff prompts, and inactive Pro upsell helpers are retired.
Self-hosted guest capacity caps are removed; self-hosted Pro
continuity holds with no caps.
- The release pipeline now ships `install.sh` as a GitHub Release
asset, gates the release on an end-to-end `install.sh` smoke test
against the published release, and self-tests the smoke gate on
every workflow edit. The archive install path requires a `.sshsig`
sidecar. Windows agent onboarding moved to a seamless install flow.
### What if a user evaluated `rc.1`-`rc.5` on the unified IA and held back?
`rc.6` is the build to retest. Explain plainly: the unified IA
feedback was consistently in favour of the platform-shaped navigation
v5 had, and the frontend reverted on the same v6 backend. No data
migration is needed because the resource model and `/api/resources`
contract did not change.
### What if a user complains that "the navigation keeps changing"?
Acknowledge it. `rc.1`-`rc.5` was a frontend information architecture
experiment that operator feedback did not support. `rc.6` resets the
frontend to the platform-shaped shape v5 had, and the intent is for
that to remain the v6 frontend shape going forward. The unified
backend remains so future features can rely on a single resource
contract without reshuffling the top-level navigation again.
### What if a Patrol finding does not auto-acknowledge during a maintenance window?
Confirm that the resource has an active maintenance-window operator-
state entry (`/api/resources/{id}/operator-state`), and that the
finding's created-at timestamp falls inside the window. If both are
true and the finding still surfaces, collect the resource ID, the
operator-state payload, the finding ID, and Patrol session logs and
escalate.
### What if `/api/actions/{id}/execute` returns `plan_drift:` or `resource_remediation_locked:`?
That is the expected fail-closed behavior:
- `plan_drift:` means the executed payload no longer matches the
approved plan hash; an audit entry is persisted and the operator
should review the plan before re-approving
- `resource_remediation_locked:` means the target resource is
operator-locked against remediation, and the operator must either
remove the lock or reroute the action
Both prefixes reach the wire verbatim so agents and UI can branch on
codes.
### What if a hosted, checkout, magic-link, or SSO flow still keys access by email?
Escalate it as an identity regression. `rc.6` continues the `rc.5`
expectation that stable user and organization principals are used at
those trust boundaries.
### What if a fresh Proxmox LXC stable install lands on a v6 RC?
Treat that as a release-blocking install regression. The stable path
should resolve to v5.1.32 unless the user intentionally chose a v6
prerelease.
### What if a Docker agent duplicates or loses identity after recreation?
Collect logs and escalate. `rc.6` keeps the prior reconnect-token and
host-identity binding work and the root-agent and Proxmox token ACL
hardening from `rc.4` / `rc.5`.
### What if `install.sh` does not validate the `.sshsig` sidecar?
Escalate as a release-pipeline regression. The archive install path
in `rc.6` requires a `.sshsig` sidecar; a path that completes without
the sidecar check is a regression in the installer extraction
hardening.
### Are public issue comments or closures required for the RC?
No public GitHub state changes are required just to prepare this
packet. Draft comments, closures, or retitles still need explicit
maintainer approval before posting.
## Recommended Evaluation Path
1. Back up the current system and keep direct console access
available.
2. Confirm the current stable rollback command:
`./scripts/install.sh --version v5.1.32`
3. If the host was on `rc.2`, use a manual reinstall or explicit
trust-migration path rather than assuming unattended auto-update
continuity.
4. Upgrade the Pulse server in a staging or otherwise controlled
environment.
5. Verify server health, version, logs, and update UI before
upgrading agents.
6. Walk the frontend top-level navigation: each of Proxmox, Docker,
Kubernetes, TrueNAS, vSphere, Standalone (Machines) loads as its
own page. Confirm no `/infrastructure`, `/workloads`, `/storage`,
or `/recovery` aggregate routes remain. Confirm Command Palette
(`Cmd/Ctrl+K`) navigates across platforms and the platform-keyed
shortcuts (`g p / g d / g k / g n / g v / g s / g a / g r / g t`)
work.
7. Exercise vSphere as a first-class platform: VMs through workloads,
network inventory, hosts with version and uptime, cluster services,
VM hardware config, VMware Tools status, vCenter MoRef in workload
ID, snapshot trees, vSphere placement card in the drawer.
8. Exercise Machines: row identity, expansion affordance, IP / disk
I/O / RAID / network / temperature detail tooltips, aggregate disk
summary, SMART fallback, machine discovery drawer tabs.
9. Exercise TrueNAS native details: storage, system, service,
protection rows, overview health alerts, alert detail rows in the
drawer.
10. Exercise Proxmox backup tabs: click-sort across the three tabs,
canonical ProgressBar, hidden Replication tab on no-signals,
workload-row backup-age, recovery coverage view.
11. Exercise FilterBar + SavedViews: Alerts history, audit log
filter, embedded workloads filter, Storage SavedViews, default-
star visible, URL-backed workload search and `statusMode`.
12. Exercise Patrol: capacity-forecast action template, forecast
proposals on RemediationPlan, flapping-alert reliability finding,
PDM HTTP alert bridge.
13. Exercise the external agent substrate from `cmd/agent-probe`,
`cmd/pulse-mcp`, or an external client. Confirm `plan_drift:` and
`resource_remediation_locked:` token prefixes reach the wire
verbatim.
14. Approve an action plan, drift the payload, and confirm dispatch
refuses with `plan_drift:`. Approve another plan, run it cleanly,
and confirm the verification outcome renders on the action
history row and on `action.completed` SSE.
15. Run a Pulse Pro report with the AI narrative layer enabled and
confirm cost is recorded. Call `pulse_summarize` from Assistant
and confirm the same narrator is reachable.
16. Confirm the free-first self-hosted posture: no trial start route,
no AI quickstart surfaces, no guest capacity caps, Pro continuity
holds.
17. Re-test the `install.sh` end-to-end smoke gate against the
published release; confirm the archive path requires a `.sshsig`
sidecar; confirm Windows agent onboarding completes through the
seamless install flow.
18. Re-test release artifact download, checksum/signature, installer,
and draft validation paths before broader retesting.
19. Upgrade agents separately only when the user is explicitly
testing the v5-to-v6 agent path.
## Ask For These Details
When a user reports an `rc.6` problem, ask for:
- current version and prior version
- install type
- whether the host was previously on v5, `rc.1`, `rc.2`, `rc.3`,
`rc.4`, or `rc.5`
- whether a manual reinstall or trust migration was used after `rc.2`
- whether the issue happened during server upgrade, agent upgrade,
identity handoff, checkout, SSO, action planning, action execution,
agent-substrate use, Patrol, alerting, AI reporting, availability
probes, backup/recovery, platform inventory, frontend navigation,
vSphere inventory, Machines detail, TrueNAS detail, Proxmox backup
tab interaction, FilterBar/SavedViews interaction, or first use
- whether Unified Agents were upgraded yet
- expected result
- actual result
- sanitized logs, screenshots, and diagnostics
## Escalate Immediately
Escalate without asking the user to keep experimenting when the
report involves:
- failed install or failed upgrade with no recovery path
- stable install path unexpectedly landing on a v6 prerelease
- duplicate or missing agent identity after a v5-to-v6 upgrade
- hosted, checkout, magic-link, SSO, webhook, or token access granted
to the wrong principal
- action execution that proceeds when dry-run or plan-hash validation
failed
- agent-substrate endpoints returning data scoped to a tenant other
than the requester
- Patrol auto-acknowledge or operator-state suppression behaving
inconsistently with the recorded operator intent
- monitoring or reporting that stops entirely after upgrade
- rollback failure or inability to return to v5.1.32
- SSO setup or login blocked by an unexpected paid-license
requirement
- `install.sh` archive path completing without `.sshsig` sidecar
validation
- data-loss, destructive behavior, or security-sensitive regressions
## Canonical References
- `docs/releases/RELEASE_NOTES_v6_RC6_DRAFT.md`
- `docs/releases/V6_CHANGELOG_RC6_DRAFT.md`
- `docs/releases/RELEASE_NOTES_v6.md`
- `docs/releases/V6_CHANGELOG.md`
- `docs/UPGRADE_v6.md`
- `docs/AGENT_SUBSTRATE.md`
- `docs/AGENT_SECURITY.md`
- `docs/MIGRATION_UNIFIED_NAV.md` (historical reference for the
`rc.1`-`rc.5` unified-IA migration that was reverted in `rc.6`)