The reviewed contributor-guide update left its public docs mirror stale, which breaks public-docs and frontend CI. Keep the shipped copy identical to the source without changing reviewed commits.
Change-source: pulse-maintainer
The feedback form forced screenshots into shell code fences and conflated a running container image with a non-container release asset. Preserve rendered attachments, ask for the Pulse image only on running containers, and keep failed-install evidence truthful.
Contract-Neutral: Community issue intake only; release and installation contracts unchanged.
Change-source: pulse-maintainer
The contributor guide still demanded reproduction steps and a running image even when an install never started or another attempt could cause an outage. Match the current issue forms: accept the original sequence, attempted release, installer provenance and only safely collected redacted evidence.
Contract-Neutral: Contributor reporting guidance only; no installation, release, or runtime contract change.
Change-source: pulse-maintainer
Keep resource maintenance, mute and expected-offline policy terminal in the internal alert callback path. Quiet-hours deferral remains replayable, while delivery diagnosis and event history report the actual operator suppression. Cover pre-reconciliation active alerts and unaffected performance signals.
Change-source: pulse-maintainer
The bug and v6 pre-release forms previously required reproduction steps even when a retry could cause a host outage, duplicate update, alert storm or data loss. Ask for the original sequence and safe evidence instead, and mirror the guidance in the public triage document.
Contract-Neutral: Community intake wording only; release and installation contracts unchanged.
Change-source: pulse-maintainer
Avoid configuration-history rows when source merges only reorder identity addresses or represent an absent list as empty. Real identity changes remain recorded. The #2319 serial-bearing disk fixture and registry-generation check cover the tags-only and no-op identity paths.
Change-source: pulse-maintainer
Ask for the attempted release and installer provenance when Pulse never started, without forcing a false running-version attestation or a token-bearing command. Keep public triage guidance aligned and pin both forms in tests.
Contract-Neutral: Issue form provenance and wording change community intake only, not release promotion or artifact dispatch
Change-source: pulse-maintainer
The intake contract changed for non-container reports and secondary topics, but the shipped public copy remained stale. Mirror the current source so in-app guidance and the docs parity check agree.
Contract-Neutral: Documentation mirror only; no runtime contract change
Change-source: pulse-maintainer
Linked Agent SMART disks inherit a PVE instance for presentation. Restrict skipped-poll readback to actual PVE observations so an empty disks/list cannot alternate fabricated inventory, tags and history rows. Pin repeated cycles and the source boundary in the monitoring contracts.
Change-source: pulse-maintainer
Copy the current repository issue-triage instructions into the shipped public docs asset. This restores mirror integrity and makes the clarified intake guidance available in-product.
Contract-Neutral: This mirrors already-recorded guidance without changing issue handling.
Change-source: pulse-maintainer
Preserve the registry-corroborated PBS-to-Agent link on the service row while selecting the Agent host metrics target in the Backups drawer. Reject PVE-only name collisions and retain the target through a transient missing host row. Recompose the unchanged #1723 runtime repair on current main with fresh desktop and phone browser proof.
Change-source: pulse-maintainer
Retain the verified #2321 source and its original receipt while incorporating upstream release and browser range validation.
Change-source: pulse-maintainer
Preserve the browser-verified #2321 repair and current protected Relay changes in separate ancestry. Resolve the shared receipt to the current main version; both proofs remain in their original non-merge commits.
Change-source: pulse-maintainer
The maintainer coordinator merges reviewed candidates onto a main that
keeps moving and then ran the browser verification guard once over the
whole range with the merge tip as the commit. No lane can produce a
receipt bound to that merge's parent and covering upstream frontend work
too, so 13 of 13 coordinator browser-guard rollbacks since 28 September
failed on base_sha. This adds a range mode where every changed frontend
file's final content must match a valid receipt from a non-merge commit
inside the range, each validated against its own commit. Merge-authored
receipts never count, and the per-commit and staged modes are unchanged.
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.
The maintainer coordinator integrates reviewed candidates by merge onto a
main that keeps moving, then ran this guard once over before..after with
--commit after. That demands one tip receipt whose base_sha is the tip's
parent and whose paths and digests cover the whole cumulative delta. The
tip is a merge and the range carries the candidate plus upstream work that
was verified on its own, so no lane could ever produce that receipt. 13 of
13 coordinator browser-guard rollbacks since 28 September failed on
base_sha for this reason.
Add --base <range-base> for range mode. Every changed user-visible
frontend file's content at the tip must equal a digest recorded by a valid
receipt in a non-merge commit inside the range, and each receipt is
validated as the per-commit guard validates it at its own commit, bound to
that commit's parent and tree. Merge-authored receipts are never evidence,
so a conflict resolution or a later correction that changes frontend
source still needs fresh proof for the final content. Replaying the three
rolled-back 29 September batches from the host passes, and the existing
per-commit and staged modes are unchanged.
Preserve upstream browser verification for the newer Relay retirement surface; earlier action recovery proof remains in reviewed ancestry. Include current CI sharding and qualification canary without rewriting accepted commits.
Change-source: pulse-maintainer
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.
Prevent unrelated estate-wide VM and storage counts from advertising Proxmox sections, while retaining direct-link hydration and the PBS-only Backups path. Revalidate the compact facet request when an all-resources cache supplies rows without scoped counts; cover mixed-source counts in component and browser proof and update both subsystem contracts.
Change-source: pulse-maintainer
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.
An empty form field or unrelated edit cannot prove comment-raised topics were dispositioned. Only label newly declared topics, leaving removal to whole-thread triage and respecting a completed manual disposition.
Change-source: pulse-maintainer
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.
The #1891 pending-receipt recovery adds explicit resource-state confirmation, an inconclusive audit result, and a fresh server read to ActionReviewDialog. Exact-head PR #2323 built and passed frontend tests but found this one chunk at 8.25 KiB against the August 6.89 KiB baseline and 7.93 KiB ceiling; all other chunks and totals passed. Raise only this chunk baseline to the upper byte bound of that rounded observation (8453 bytes), retaining the 15 percent growth guard and all recovery safety checks. The post-change exact-source build and protected CI remain qualification gates.
Change-source: pulse-maintainer
Ask for the failing running version and a container image only where one exists. Accept symptom-appropriate screenshots or logs without forcing irrelevant log text, and state the matching triage rule.
Change-source: pulse-maintainer
Carry the validated #2321 web candidate across the protected main frontier without changing its runtime or browser contract. Change-source: pulse-maintainer
Change-source: pulse-maintainer
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.
Avoid showing unsupported Replication, Ceph and Mail Gateway sections while Proxmox resource counts are unknown, while preserving bookmarked-route hydration and legitimate PBS navigation. Cover count transitions in component tests and synthetic production-page desktop/phone browser verification; update the affected subsystem contracts and receipt.
Change-source: pulse-maintainer
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.
Create the non-loopback veth canary only inside the no-network disposable systemd container before running the immutable release lab. Preserve packet authentication and fail closed when the local interface or no-default-route assertion is absent. Bind the workflow, source contract and installtests guard in one reviewed candidate.
Change-source: pulse-maintainer
The scheduled release dry run reached its reusable demo resolver before checkout, so the output helper was absent and the no-mutation demo check failed. Move the credential-free checkout ahead of resolution, guard the ordering in install tests, and record that precondition in the deployment-installability contract.
Change-source: pulse-maintainer
Expose the existing admin audit escape hatch in the shared Actions review with direct-state confirmation, fresh re-read, and inconclusive outcome presentation. Keep server authorization and transport truth unchanged. Record affected canonical contracts and fresh desktop/phone browser verification in the same candidate.
Change-source: pulse-maintainer
## 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)
pulse-triage[bot]