Follow-up to #2328. With the canary fixed, v6.4.5-rc.4 passed the
systemd and rootful Docker lab in run 36594651903, then attestation
failed reading receipt.json because the privileged lab writes it as root
into the bind-mounted evidence directory. This chowns that directory to
the runner user after a passing lab and before attestation, and pins the
ordering in the workflow test.
With the host-interface canary in place, v6.4.5-rc.4 passed the
schema-v7 systemd and rootful Docker lab (run 36594651903), but the
attestation step then failed with Permission denied on receipt.json,
which the privileged lab writes as root into the bind-mounted evidence
directory. Hand that directory to the runner user after a passing lab
and before attestation, without touching its content.
Split out of #2323. The v6.4.5-rc.4 installed-acceptance run
(36547091547) failed before the lab because the no-network qualification
container had no non-loopback IPv4 canary. This carries only the
qualification and demo-resolver workflow fixes, their
deployment-installability contract text and the workflow tests, so
promotion isn't waiting on #2323's conflicting UI changes.
The immutable RC systemd lab failed before installed acceptance because
its --network none container had no non-loopback IPv4 address to prove
the helper's private network cannot reach. Add a veth canary wholly
inside that namespace and assert no default route before the lab runs.
Also check out the repository in the demo resolver before it calls
scripts/write_github_output.py, so verification-only dry runs reach
their demo checks.
Split out of #2323 so the v6.4.5 promotion is not held behind the
unrelated action-review UI work in that PR.
The weights from #2324 came from one local run and left the api shards
at
4.5, 8.8, 17.1 and 12.5 minutes on CI. Most of the 17.1 was not test
time.
That shard ran `-run . -skip <1231 names>`, and the test binary caches
only
its last compiled pattern, so alternating the two recompiled the 62 KB
skip
regex for every test and subtest (about 50 ms each under -race locally,
30s
against 1.3s for 300 trivial tests). Two runs put that shard at 887s and
875s against roughly 450s of tests. The skip path now passes -skip
alone.
Every api shard now runs go test -json through
.github/scripts/record-internal-api-test-seconds.py. It prints what
plain go
test would (package lines and the output of failing or unfinished
tests),
exits non-zero on any failure behind pipefail, and writes each top-level
test's seconds to an internal-api-test-seconds-N artifact that is
uploaded
even when the shard fails.
.github/scripts/refresh-internal-api-test-seconds.py
rebuilds the weights file from those artifacts (gh run download, median
across runs, DEFAULT_WEIGHT set to the mean of the unlisted tests, which
the
selector now reads from the file).
Until those artifacts exist, the weights are a local -race -json run
with
each region of go test's order scaled to what CI reported for it.
Equal-count quarters averaged 107, 437, 100 and 787s over four runs, and
the
weighted cut gave 131s for the first 1187 tests, 350s for the next 23
and
608s for the last 21 over two. The last quarter and the last 21 tests
disagree on how the tail splits, so the tail takes the midpoint of an
exact
fit and a pooled factor.
With these weights four shards still predict a slowest shard near 10
minutes, and a 20% slower runner on the tail would take it past the 11
minutes of Frontend and rest-1. Five shards predict about 131, 325,
280-340,
330-355 and 330-365s of tests, or 4.5 to 8.5 minutes a job with about
2.3
minutes of setup, so API_SHARD_COUNT goes to 5. Every test still runs
exactly once in contiguous go test order, and all five slices passed
locally
from their new starting points. The required Backend tests (api) verdict
keeps its name.
The weights from #2324 came from one local run and left the api shards at
4.5, 8.8, 17.1 and 12.5 minutes on CI. Most of the 17.1 was not test time.
That shard ran `-run . -skip <1231 names>`, and the test binary caches only
its last compiled pattern, so alternating the two recompiled the 62 KB skip
regex for every test and subtest (about 50 ms each under -race locally, 30s
against 1.3s for 300 trivial tests). Two runs put that shard at 887s and
875s against roughly 450s of tests. The skip path now passes -skip alone.
Every api shard now runs go test -json through
.github/scripts/record-internal-api-test-seconds.py. It prints what plain go
test would (package lines and the output of failing or unfinished tests),
exits non-zero on any failure behind pipefail, and writes each top-level
test's seconds to an internal-api-test-seconds-N artifact that is uploaded
even when the shard fails. .github/scripts/refresh-internal-api-test-seconds.py
rebuilds the weights file from those artifacts (gh run download, median
across runs, DEFAULT_WEIGHT set to the mean of the unlisted tests, which the
selector now reads from the file).
Until those artifacts exist, the weights are a local -race -json run with
each region of go test's order scaled to what CI reported for it.
Equal-count quarters averaged 107, 437, 100 and 787s over four runs, and the
weighted cut gave 131s for the first 1187 tests, 350s for the next 23 and
608s for the last 21 over two. The last quarter and the last 21 tests
disagree on how the tail splits, so the tail takes the midpoint of an exact
fit and a pooled factor.
With these weights four shards still predict a slowest shard near 10
minutes, and a 20% slower runner on the tail would take it past the 11
minutes of Frontend and rest-1. Five shards predict about 131, 325, 280-340,
330-355 and 330-365s of tests, or 4.5 to 8.5 minutes a job with about 2.3
minutes of setup, so API_SHARD_COUNT goes to 5. Every test still runs
exactly once in contiguous go test order, and all five slices passed locally
from their new starting points. The required Backend tests (api) verdict
keeps its name.
Relay left public checkout on 2026-09-29: it only ever connected the
Pulse Mobile app, which retires on 31 March 2027, and existing Relay
subscribers now carry Pro entitlements. The app still sold it. Every
Community install saw a "Get alerts on your phone ... Available with
Relay and Pro plans" upgrade panel on Alerts destinations, the plan
screen offered a Relay card with "Remote web access via Relay", and the
settings section was called Remote Access although Relay never reached
the web UI.
The Alerts push panel now renders only on instances that have the relay
feature, with no upsell. The settings section, nav, header and locale
catalogs say Pulse Mobile and carry the retirement date. Community sees
only the Pro comparison card and Relay-tier licenses see none; gated
mobile features name Pro as their minimum plan. The relay feature is
labelled "Pulse Relay (Mobile Connection)" in the catalog, plan copy no
longer claims remote web access, the backend pairing diagnostics point
at Settings > Pulse Mobile, and the user docs, including PRIVACY.md,
state that Relay does not provide remote web UI access.
The four Backend tests (api-N) shards took equal-count quarters of go
test's list, which left them at 4.0, 10.6, 4.0 and 16.8 minutes on the
first PR run, and at 1.9, 8.0, 1.5 and 10.3 minutes of go test time on
the following main push (run 36560070496). Almost all of it sits in a
few tests. One contract mock chart test runs about six minutes on the
runner, and the 28 integration server tests at the end of the list take
about twenty seconds each, so the fourth quarter held nearly half the
package.
Shards are still contiguous runs of go test's own order, since some
tests depend on package state from their neighbours, but the cut points
now come from estimated seconds.
.github/scripts/select-internal-api-shard.sh weighs each test from
.github/scripts/internal-api-test-seconds.txt (the 199 tests at 0.5s or
more, seeded from a local -race -json run scaled to that main run's
shard totals, with a 0.05s default for anything unlisted), binary
searches the smallest per-shard budget that fits the list into four
slices, and fills up to it. The weights only move cut points. Every test
is assigned exactly one shard in a single pass, so a stale file can
unbalance shards but never drop or repeat a test, and no shard is ever
empty.
With today's list the slices hold 1187, 23, 2556 and 21 tests, estimated
at 1.9, 6.9, 6.5 and 6.7 minutes of tests, or about 9.5 minutes per job
with the roughly 2.6 minutes of setup and race compile. The 2556-test
slice would need a 124 KB -run pattern, so a shard passes -skip of the
other shards' tests whenever that is shorter, which runs the same tests
in the same order.
The script smoke test still required "Pulse Mobile pairing for handoff"
in PRIVACY.md, the wording the previous commit replaced when it removed
the unbacked "secure remote web access" claim. Pin the new description
and forbid the remote web access wording in both copies.
Relay left public checkout on 2026-09-29: it only ever connected the
Pulse Mobile app, which retires on 31 March 2027, and existing Relay
subscribers now carry Pro entitlements. The app still sold it. Every
Community install saw a "Get alerts on your phone ... Available with
Relay and Pro plans" upgrade panel on Alerts destinations, the plan
screen offered a Relay card with "Remote web access via Relay", and the
settings section was called Remote Access although Relay never reached
the web UI.
The Alerts push panel now renders only on instances that have the relay
feature, with no upsell. The settings section, nav, header and locale
catalogs say Pulse Mobile and carry the retirement date. Community sees
only the Pro comparison card and Relay-tier licenses see none; gated
mobile features name Pro as their minimum plan. The relay feature is
labelled "Pulse Relay (Mobile Connection)" in the catalog, plan copy no
longer claims remote web access, the backend pairing diagnostics point
at Settings > Pulse Mobile, and the user docs, including PRIVACY.md,
state that Relay does not provide remote web UI access.
The four Backend tests (api-N) shards took equal-count quarters of go
test's list, which left them at 4.0, 10.6, 4.0 and 16.8 minutes on the
first PR run, and at 1.9, 8.0, 1.5 and 10.3 minutes of go test time on
the following main push (run 36560070496). Almost all of it sits in a
few tests. One contract mock chart test runs about six minutes on the
runner, and the 28 integration server tests at the end of the list take
about twenty seconds each, so the fourth quarter held nearly half the
package.
Shards are still contiguous runs of go test's own order, since some
tests depend on package state from their neighbours, but the cut points
now come from estimated seconds.
.github/scripts/select-internal-api-shard.sh weighs each test from
.github/scripts/internal-api-test-seconds.txt (the 199 tests at 0.5s or
more, seeded from a local -race -json run scaled to that main run's
shard totals, with a 0.05s default for anything unlisted), binary
searches the smallest per-shard budget that fits the list into four
slices, and fills up to it. The weights only move cut points. Every test
is assigned exactly one shard in a single pass, so a stale file can
unbalance shards but never drop or repeat a test, and no shard is ever
empty.
With today's list the slices hold 1187, 23, 2556 and 21 tests, estimated
at 1.9, 6.9, 6.5 and 6.7 minutes of tests, or about 9.5 minutes per job
with the roughly 2.6 minutes of setup and race compile. The 2556-test
slice would need a 124 KB -run pattern, so a shard passes -skip of the
other shards' tests whenever that is shorter, which runs the same tests
in the same order.
Across the last 25 bot PRs the median open to merge time was about 33
minutes for one PR and about 45 when three opened together. The critical
path was the required Backend tests (api) check, where one go test -race
./internal/api step took about 27 of its 31 minutes. Every other
required
check finishes within about 12 minutes.
internal/api now runs as four Backend tests (api-N) shards. Each shard
lists the package's tests with go test -race -list from the commit under
test and runs one contiguous quarter of that list in go test's own
order,
so every test, including ones added later, runs in exactly one shard,
and
a shard that resolves no tests fails. The split is contiguous rather
than
interleaved by name because some internal/api tests depend on package
state left by the tests just before them. A round-robin split by sorted
name failed dozens of tests locally (admin bypass and session store
globals), while the four contiguous slices and the full run all pass. A
Backend tests (api) verdict job keeps the required check name and fails
unless every shard succeeded. Backend tests (rest-0) and (rest-1) keep
their names and package split. Local non-race timings put the heaviest
slice at about 42 percent of the package, so the api check should drop
from about 31 minutes to roughly 14.
Core E2E no longer runs the non-gating probation tier on pull requests.
It could not gate a PR and the promotion rule counts only main runs, so
on a PR it only held each of the eight shard runners about eight minutes
longer, which fed the runner queueing seen with concurrent PRs. Push and
manual runs still execute it.
Go test steps still run for frontend-only changes. Go tests read
frontend sources directly (internal/api contract tests,
internal/unifiedresources walking frontend-modern/src, and the
internal/telemetry repository-wide wording scan), so skipping them by
path would drop real coverage.
Across the last 25 bot PRs the median open to merge time was about 33
minutes for one PR and about 45 when three opened together. The critical
path was the required Backend tests (api) check, where one go test -race
./internal/api step took about 27 of its 31 minutes. Every other required
check finishes within about 12 minutes.
internal/api now runs as four Backend tests (api-N) shards. Each shard
lists the package's tests with go test -race -list from the commit under
test and runs one contiguous quarter of that list in go test's own order,
so every test, including ones added later, runs in exactly one shard, and
a shard that resolves no tests fails. The split is contiguous rather than
interleaved by name because some internal/api tests depend on package
state left by the tests just before them. A round-robin split by sorted
name failed dozens of tests locally (admin bypass and session store
globals), while the four contiguous slices and the full run all pass. A
Backend tests (api) verdict job keeps the required check name and fails
unless every shard succeeded. Backend tests (rest-0) and (rest-1) keep
their names and package split. Local non-race timings put the heaviest
slice at about 42 percent of the package, so the api check should drop
from about 31 minutes to roughly 14.
Core E2E no longer runs the non-gating probation tier on pull requests.
It could not gate a PR and the promotion rule counts only main runs, so
on a PR it only held each of the eight shard runners about eight minutes
longer, which fed the runner queueing seen with concurrent PRs. Push and
manual runs still execute it.
Go test steps still run for frontend-only changes. Go tests read
frontend sources directly (internal/api contract tests,
internal/unifiedresources walking frontend-modern/src, and the
internal/telemetry repository-wide wording scan), so skipping them by
path would drop real coverage.
## What and why
Record the composed browser verification for AI-off navigation, plain
Actions empty-state guidance, first-source setup guidance, and the
Updates label. These changes address the AI-off/Actions usability work
tracked in Pulse #905 and the setup guidance repairs already merged to
main. This proposal updates the verification receipt only; it does not
introduce another UI implementation or change the frozen v6.4.5 RC.4.
## Included source
`72d8ae6f426fc4870570e983a43cef782e6f6178..496b3047e72e92ad8987994c0bfe9fe90345bfa2`
(commits `2606c9d36a`, `388770a974`, and additive merges `360e15c10d`,
`496b3047e7`). The net file change is
`frontend-modern/browser-verification.json`.
## Validation and limits
The retained offline Chromium desktop/phone browser exercise inspected
Actions, navigation, command palette, shortcuts, setup completion and
Updates with mocked authenticated API responses. This gate confirmed the
receipt's 15 source hashes still match the composed head, its verified
parent remains in ancestry, and `git diff --check` passes. Existing
protected frontend and E2E checks passed for the implementation already
on main. The mock-backed receipt is not live-backend, installed-release
or field acceptance; this proposal still needs exact-head CI.
[How Pulse handles
triage](https://github.com/rcourtman/Pulse/blob/main/docs/AI_TRANSPARENCY.md)
## What and why
- Correct structured PBS comment matching so a CT's current backup is
not shown as stale when its name is encoded as `node.VMID.name` (#2292).
- Read identified ARM sysfs temperatures when lm-sensors does not
provide a usable CPU reading, while preserving other sensor values and
collision handling, for the Synology DS216j report (#2311).
- Correct the same-RC secure-runtime qualification control needed to
verify the already-published v6.4.5-rc.4 before stable promotion. This
is control-path work, not a change to that frozen RC or evidence that
installed qualification passed.
- Align the first-source setup E2E assertion with the already-reviewed
guidance (#2309).
This proposal contains reviewed local range
`762aa6fe1a423f03138e8e7e533381f3e086e3c1..9822c2b060cf8cf4af431a41da6b21f090fbb5f6`,
with additive protected-main merge
`d20d3bd9dacaf8ad8a7bb3f95ff03af9d312a64f` (upstream
`f5651f3eb90a8f43d7e4ca7fe0c1518f719f7d3a`). The reviewed commits and
their authors are unchanged. No source from the frozen RC.4 was recut.
## Validation
The reviewed combined candidate passed focused offline race/source proof
`source-65j5yh6s` for the PBS and sensor repairs; the secure-runtime
control passed focused offline proof `source-w7kjnood`. Protected main
`f5651f3e` passed its Build and Test and E2E workflows before this
additive merge. Provenance and clean-diff checks passed on this proposal
head. A further combined source-proof request was queued behind another
job and cancelled rather than represented as a pass. Exact-head PR CI
and administrative review remain required; the same-RC hosted
installation/rollback proof and release soak remain separate gates.
[How Pulse handles
triage](https://github.com/rcourtman/Pulse/blob/main/docs/AI_TRANSPARENCY.md)
Record fresh offline Chromium evidence for the exact merged web source at 2606c9d36a. The per-commit browser guard requires that verified parent, not the earlier assigned candidate base. Preserve the original protected merges and setup assertion without replaying the UI proof.
Change-source: pulse-maintainer
Compose protected Pulse PRs #2312 and #2313 with the reviewed main candidate so first-source setup guidance, the corrected E2E assertion, and later repairs can be verified together. Browser proof for the composed source follows in a separate receipt commit.
Change-source: pulse-maintainer
#2309 reworded the empty setup-complete next step so it no longer
promises temperatures and SMART on every Proxmox host, but the
stable-tier E2E spec `30-setup-platform-connections-handoff` still
waited for the old sentence. Core E2E has failed on main since that
merge. This expects the current English copy; every other string the
spec asserts is present in source.
With AI switched off the empty Actions inbox still said "Patrol runs in
Watch only mode" and pitched Pulse Pro modes, because the autonomy
setting reads as monitor even when Patrol is not running at all. That
tells an AI-off user something untrue and turns an empty page into an
upsell for a feature they turned off (issue #905).
The guidance now requires the same assistantEnabled session capability
that gates the Assistant launcher and the Patrol navigation, and falls
back to the plain empty-state copy otherwise.
Stacked on #2312; once that lands only this commit remains.
Issue #905 asked for every AI entry point to disappear when AI is
switched off, and the Assistant launcher still honours that through the
assistantEnabled session capability. Patrol did not: v6 added it as a
permanent top-level tab, mobile bottom-bar slot, g r shortcut and
command-palette entry, and the palette also kept offering Assistant
commands. Patrol cannot run without a configured provider, so an AI-off
install carried a tab that only led to an "off" page.
Gate all of those on the same capability as the Assistant launcher.
Settings keeps its Patrol and Assistant items and /patrol stays
reachable, so the path back to turning AI on is unchanged.
Also rename the System settings item "Pulse server updates" to
"Updates" and drop "runtime" from its description. The item already sits
in the System group, and the description still sends agent updates to
Infrastructure, which was the reason for the longer name.
#2309 reworded the empty setup-complete next step so it no longer
promises temperatures and SMART on every Proxmox host, but the stable
tier E2E spec still waited for the old sentence. Core E2E has failed on
main since that merge. Expect the current English copy.
Contract-Neutral: Test copy follows #2309; no runtime change
With AI switched off the empty Actions inbox still said "Patrol runs in
Watch only mode" and pitched Pulse Pro modes, because the autonomy
setting reads as monitor even when Patrol is not running at all. That
tells an AI-off user something untrue and turns an empty page into an
upsell for a feature they turned off (issue #905).
The guidance now requires the same assistantEnabled session capability
that gates the Assistant launcher and the Patrol navigation, and falls
back to the plain empty-state copy otherwise.
Issue #905 asked for every AI entry point to disappear when AI is
switched off, and the Assistant launcher still honours that through the
assistantEnabled session capability. Patrol did not: v6 added it as a
permanent top-level tab, mobile bottom-bar slot, g r shortcut and
command-palette entry, and the palette also kept offering Assistant
commands. Patrol cannot run without a configured provider, so an AI-off
install carried a tab that only led to an "off" page.
Gate all of those on the same capability as the Assistant launcher.
Settings keeps its Patrol and Assistant items and /patrol stays
reachable, so the path back to turning AI on is unchanged.
Also rename the System settings item "Pulse server updates" to
"Updates" and drop "runtime" from its description. The item already sits
in the System group, and the description still sends agent updates to
Infrastructure, which was the reason for the longer name.
An existing cpu_thermal chip with an unusable CPU value can still carry valid fan readings. Use a free synthetic CPU-chip key instead of replacing that entry when supplementing Pulse #2311, and cover the collision with a regression test.
Change-source: pulse-maintainer
Dispatch the post-publication check from protected main while binding its packet to the immutable RC tag. Accept only canonical Pulse checkout origins before normalising the spelling required by the attester, and document the deployment contract and source guard together.
Change-source: pulse-maintainer
A named CPU chip with no valid CPU temperature must not suppress an identified SoC thermal reading. Preserve other lm-sensors readings and existing valid CPU precedence.
Change-source: pulse-maintainer
When lm-sensors returns disk or other readings without a CPU chip, retain those readings and add a bounded, identified SoC temperature from sysfs. Preserve existing CPU output and ignore unusable optional sysfs data. Cover combined and precedence paths for Pulse #2311.
Change-source: pulse-maintainer
Fall back to bounded, type-checked thermal-zone and hwmon sysfs readings when lm-sensors is absent or empty. Classify Armada thermal JSON as a CPU reading, preserve nonempty sensor output, and cover units, invalid values, and the agent mapping.
Change-source: pulse-maintainer
The main first-source wording changed in #2309, but the integration test still required the superseded sentence. Assert the reviewed host/API distinction while retaining the existing infrastructure navigation checks.
Change-source: pulse-maintainer
Recognise exact node.VMID.name notes on Root PBS snapshots so a newer completed CT backup can replace an older name-only match. Keep colliding VMIDs fail-closed when node and name do not distinguish connections, and cover completed and in-flight attribution for Pulse #2292.
Contract-Neutral: Preserve backup attribution safety without changing API fields, persisted shapes, or source contracts.
Change-source: pulse-maintainer
## What changed
Correct the first-source setup screen so API connections, agent
installation, and optional host-local temperature/SMART coverage are
described accurately in English, German and Spanish. The guidance no
longer promises sensors on every Proxmox host. Installer behaviour and
sensor support are unchanged.
## Why
The wording introduced with first-source setup (#2303) could lead users
to expect sensor readings that depend on their platform and hardware.
This is a copy-only correction to that user-facing guidance.
## Included source
Reviewed commits `ab4f04da3d67d20c51943666be9bf4515ebb3b3f` through
`2e428460eedea66e72c5291383c961847e4d3b42`, after published main
`4de772658b338d5ddca9bf7012b4b7f220edde88`.
## Validation
The exact reviewed head passed offline `npm ci`, type-check, lint, the
full frontend test suite and production build (source proof
`source-erujaq9i`). Twelve Chromium locale, data-state and viewport
previews passed without page errors or horizontal overflow. The range
passed metadata provenance and diff checks. Protected exact-head PR
checks remain required before landing; this does not imply a release.
[How Pulse handles
triage](https://github.com/rcourtman/Pulse/blob/main/docs/AI_TRANSPARENCY.md)
The API-connected next step and combined-source option still implied that installing a Proxmox agent always supplies temperature and SMART readings. Describe them as host-local telemetry only where available in English, German and Spanish, cover both states in tests, and bind twelve rendered locale/viewport states.
Contract-Neutral: Copy-only clarification of conditional sensor coverage; installer behaviour, sensor support and credential scopes are unchanged.
Change-source: pulse-maintainer
Make the setup-completion guidance explain that users run the host installer
and that sensor and workload coverage varies by platform. Align English,
German and Spanish copy, update coverage tests, and bind a rendered desktop
and narrow-browser receipt.
Contract-Neutral: Correct misleading first-source copy only; installer behaviour, sensor support and credential scopes are unchanged.
Change-source: pulse-maintainer
The resolver refused a stable promotion until its candidate had soaked
for 72 hours, or 168 for a minor. Few installs run previews: 35 of about
7,900 active installs ran v6.4.5-rc.3 in the week to 2026-09-28, while
75 percent sat on a month-old stable. The minimums drop to 24 hours for
minor and patch alike; the content-drift check and the hotfix exception
are unchanged. The workflow and trigger prompts, the promotion policy
and the deployment-installability contract say the same.
After security setup, the screen asked new users to choose "how the
first
system should enter the unified infrastructure model: platform API
inventory, Pulse Agent telemetry, or both", under a "Choose the first
source strategy" heading. Someone who only wants their Proxmox server on
screen knows none of those terms, and this is where most never-activated
installs stop: in the week to 2026-09-28, 280 of 596 persistent installs
that never monitored anything had finished security setup and then never
configured a connection.
The screen keeps its structure and routing. The copy now says what to
do and what each path shows: connect Proxmox, TrueNAS or VMware by API
with nothing to install, add the agent for temperatures, disk health and
Docker, or both. German and Spanish follow, and the agent-lifecycle
contract records the plain-words rule.
Contract-Neutral: copy-only: plain-language first-source setup copy;
owning agent-lifecycle clause updated; no runtime, API or primitive
change
## What and why
Stabilise agent update-readiness and monitoring history-window tests
without weakening their assertions. The failed v6.4.5-rc.4 exact
preflight (packet 20260928T080527Z-release) exposed timing-sensitive
failures that could block the #2282 updater repair from reaching a
qualified release. This main-line batch also incorporates the
already-published dropped-session dispatch repair from Pulse #2300 and
container-console setup guidance from #2302 without rewriting either
reviewed test commit.
## Included range
Pulse `main`
`75c72ef505b24e31214162b7b46f97e357528ae3..cbb9122bcc216e335867fa4fed98c4451b12bd27`:
reviewed test candidates `bc3a7306` and `383e05ae`, followed by additive
upstream integrations `894d7409` and `cbb9122b` (published main
`ad15366f`).
## Validation
Provenance, clean-tree and diff checks passed. Committed-source offline
race proof `source-_ki_8c7c` passed the named failure tests for 20
repetitions. The composed v6.4 counterpart passed the full affected
packages with race detection (`source-7g64cyz2`). Exact-head GitHub
checks remain required before merge; source tests do not qualify or
publish v6.4.5.
[How Pulse handles
triage](https://github.com/rcourtman/Pulse/blob/main/docs/AI_TRANSPARENCY.md)
The resolver refused a stable promotion until its candidate had soaked for
72 hours, or 168 for a minor. Few installs run previews: 35 of about 7,900
active installs ran v6.4.5-rc.3 in the week to 2026-09-28, so a longer
soak saw little the first day did not, while 75 percent of installs sat on
a stable build a month old. Richard set a 24 hour soak for every release
on 2026-09-28.
The minimums drop to 24 hours for minor and patch alike, the error text
reads the constants instead of repeating numbers, and the workflow and
trigger prompts, the promotion policy and the deployment contract say the
same. The content-drift check and the hotfix exception are unchanged.
The first rewrite told users that Proxmox, TrueNAS and VMware need
nothing installed, which reads as "do not put the agent on them". On
Proxmox that is wrong: the API does not report node temperatures or SMART
disk health, and the agent on each node does. TrueNAS already reports
both through its API, and ESXi hosts take no agent, so the copy now says
to start with the API and add the agent on Proxmox nodes.
Contract-Neutral: copy-only: correct first-source copy about the agent on Proxmox nodes; no runtime, API or primitive change
After security setup, the screen asked new users to choose "how the first
system should enter the unified infrastructure model: platform API
inventory, Pulse Agent telemetry, or both", under a "Choose the first
source strategy" heading. Someone who only wants their Proxmox server on
screen knows none of those terms, and this is where most never-activated
installs stop: in the week to 2026-09-28, 280 of 596 persistent installs
that never monitored anything had finished security setup and then never
configured a connection.
The screen keeps its structure and routing. The copy now says what to
do and what each path shows: connect Proxmox, TrueNAS or VMware by API
with nothing to install, add the agent for temperatures, disk health and
Docker, or both. German and Spanish follow, and the agent-lifecycle
contract records the plain-words rule.
Contract-Neutral: copy-only: plain-language first-source setup copy; owning agent-lifecycle clause updated; no runtime, API or primitive change
The unlock screen told Docker users to run `docker exec` from the host,
which does not fit the Unraid, Portainer and TrueNAS app UIs, where the
console already runs inside the container. Those `container_other`
installs are the largest group stalling before first setup: in the week
to 2026-09-28, 158 of 3114 persistent Docker installs never got past
first start, against 94 of 5462 binary and systemd installs.
The startup log also suggested revealing the token "by reading the token
file path". That file holds ciphertext, as the security-privacy contract
requires, so anyone following the hint pasted JSON the unlock screen
rejects. The log now names the command, including the console form, and
the install docs and the contract gain the same guidance.
Contract-Neutral: copy-only: new unlock-screen command row and corrected
startup log text; no API payload, lifecycle, storage or primitive
change; owning security-privacy clause updated
The unlock screen told Docker users to run `docker exec` from the host,
which does not fit the Unraid, Portainer and TrueNAS app UIs, where the
console already runs inside the container. Those `container_other`
installs are the largest group stalling before first setup: in the week
to 2026-09-28, 158 of 3114 persistent Docker installs never got past
first start, against 94 of 5462 binary and systemd installs.
The startup log also suggested revealing the token "by reading the token
file path". That file holds ciphertext, as the security-privacy contract
requires, so anyone following the hint pasted JSON the unlock screen
rejects. The log now names the command, including the console form, and
the install docs and the contract gain the same guidance.
Contract-Neutral: copy-only: new unlock-screen command row and corrected startup log text; no API payload, lifecycle, storage or primitive change; owning security-privacy clause updated
The supervisor sends its commit call before returning, but both channels can be ready when the test wakes. Treat a completed successful supervisor with the recorded commit as success, and bound the post-commit wait.
Change-source: pulse-maintainer
rcourtman