Commit Graph

9659 Commits

Author SHA1 Message Date
rcourtman 3d48649867 feat(alerts): re-fire start restoration in the reducer with parity harness
Phase 1 slice 4 of docs/ALERT_ENGINE_EVOLUTION.md. The reducer now keeps
a resolved-occurrence ledger: an activation inside RefireRetention (5
minutes, on the signal clock) consumes the record, restores the original
occurrence's StartedAt, and emits EventRefired — mirroring
consumeRecentlyResolvedForRefireWithPrimaryLock, where a re-fire within
the recently-resolved window reactivates the same occurrence without a
new history entry. Outside the window the re-fire is a fresh occurrence
with a fresh start.

reducer_parity_refire_test.go anchors the simulated epoch at wall time
and backdates recentlyResolved timestamps per step so the manager's
wall-clock retention check follows simulated time; StartTime is asserted
exactly on both engines. First parity slice with no manager defect
found. The wall-vs-evidence clock mix in the manager's retention check
is recorded as a deliberately deferred nuance.
2026-08-26 23:19:04 +01:00
rcourtman 07aa2116d1 feat(alerts): recovery-confirmation gate in the reducer with composed parity harness
Phase 1 slice 3 of docs/ALERT_ENGINE_EVOLUTION.md.
DiscreteRule.RecoveryConfirmations characterizes the poll-driven offline
composition: a firing incident resolves only after N consecutive
non-matching observations (default 3, storage 2), any matching
observation resets the run, pending still clears on a single
non-matching observation, and disable bypasses the gate — mirroring
clearResourceOfflineAlert + confirmOfflineRecoveryNoLock.

reducer_parity_recovery_test.go drives the manager through the exact
production composition (offline poll: reset recovery counter + evaluate
connectivity spec; healthy poll: clearResourceOfflineAlert) and diffs
the reducer after every step, including first-activation StartTime. The
harness caught the stale first-matched backdating fixed in the previous
commit.
2026-08-26 23:13:11 +01:00
rcourtman 44b85f754b fix(alerts): re-stamp lifecycle first-matched time when a new confirmation run starts
The slice-2 first-matched preservation kept an entry as long as one
existed, but several callers reset the confirmation-count maps directly
without the evaluator path — clearResourceOfflineAlert among them — so
a stale entry from a prior run backdated the next run's alert to the
previous run's first observation. Stamp the first-matched time whenever
the pre-evaluation count is zero, making stale entries harmless at
every reset site. Found by the recovery-gate parity harness.
2026-08-26 23:13:11 +01:00
pulse-triage[bot] de489abc65 Repair confirmation reducer governance proof
Record discrete confirmation and first-match timing ownership in the alerts contract, move the manager regression into the recognized incident proof, and restore status revision alignment with the stable source of truth.

Change-source: pulse-maintainer
2026-08-26 23:07:52 +01:00
rcourtman bb5fddf463 feat(alerts): confirmation-family reducer with discrete parity harness
Phase 1 slice 2 of docs/ALERT_ENGINE_EVOLUTION.md. ApplyDiscrete
characterizes the canonical lifecycle path's match-spec semantics for
connectivity / powered-state / discrete-state kinds: N consecutive
matching observations activate with StartTime at the first match, one
non-matching observation clears at this layer, severity follows the
spec while firing, and a disabled spec resolves. The incident sub-key
generalizes from metric name to state key.

reducer_parity_discrete_test.go diffs the reducer against
evaluateCanonicalLifecycleAlert after every step with fully simulated
time on both sides, including alert StartTime on first activations. The
harness again caught a real defect on first run — the confirmation
start-time understatement fixed in the previous commit. Recovery
confirmations and re-fire start restoration are documented as later
slices.
2026-08-26 23:04:35 +01:00
rcourtman 7c256cd04c fix(alerts): stamp confirmation-based lifecycle alerts at the first matched observation
The confirmation maps persist only counts, so lifecyclePreviousState
reconstructed pending runs dated at the current observation and a
confirmation-based alert (node/PBS/PMG offline, discrete states) stamped
StartTime at the final confirming poll — understating outage start by
the whole confirmation window. The manager had already fixed this class
once for unified incidents (unifiedIncidentFirstSeen) but not for the
generic canonical lifecycle path.

Preserve the first matched observation per tracking key
(lifecycleFirstMatched), consume it when reconstructing pending state,
clear it with the confirmation run, and clean leaked entries alongside
the other tracking maps. Found by the Phase 1 discrete-family parity
harness on its first run.
2026-08-26 23:04:35 +01:00
pulse-triage[bot] b1867a1de2 Repair metric reducer governance proof
Record canonical metric resolution and reducer parity ownership in the alerts contract, move the stale-resolution regression into the recognized shared proof, and restore deterministic status evidence ordering.

Change-source: pulse-maintainer
2026-08-26 23:00:46 +01:00
rcourtman 4223357449 release-control: release alert-lifecycle-contract-coverage claim (metric-family slice landed) 2026-08-26 22:53:36 +01:00
rcourtman 7c212b906e feat(alerts): deterministic metric-transition reducer with manager parity harness
Phase 1 of docs/ALERT_ENGINE_EVOLUTION.md. internal/alerts/reducer is a
pure transition core for the metric-threshold family — hysteresis
trigger/clear, sustained-for delay with dip reset, warning/critical
severity derivation with the percentage 99-cap — characterized from
Manager.checkMetric, with time entering only through the signal's
ObservedAt so every sequence is deterministic and replayable.

reducer_parity_test.go drives the live manager and the reducer through
identical observation sequences (simulated time via the established
pending-backdate trick) and fails on any divergence after every step,
with the manager as the reference. The harness proved itself on its
first run by catching the stale-resolve defect fixed in the previous
commit.

Registers coverage gap alert-lifecycle-contract-coverage. Remaining
slices: offline/confirmation families, ack lifecycle, intent
interaction, shadow-mode runtime feed.
2026-08-26 22:53:26 +01:00
rcourtman 20ea1ea4d3 fix(alerts): resolve canonically keyed metric alerts instead of leaving them stale
checkMetric stores canonical-identity alerts under the canonical state
key, but its hysteresis resolution removed by the legacy
<resourceID>-<metric> ID, which is never registered as an alias. The
removal silently no-oped: a resolved notification went out and a
recently-resolved entry was created while the alert stayed active and
re-resolved on every subsequent poll. Guest per-disk usage alerts were
the remaining production caller of this path — user-visible as the
stale-alert class (#1580).

Remove by the alert's actual storage key. Found by the Phase 1 reducer
parity harness on its first run.
2026-08-26 22:53:26 +01:00
pulse-triage[bot] 3fd5e1a50c Repair held-notification governance proof
Bind the combined delivery-attempt and held-event activity surface to the alerts, API, and frontend contracts. Add recognized state and presentation proofs and record desktop, refresh, and narrow-browser verification for the current feature commit.

Change-source: pulse-maintainer
2026-08-26 22:52:10 +01:00
rcourtman 954ea1050a feat(alerts): show held notifications in the delivery activity card
Recent delivery activity now interleaves held-notification events from
the alert event log with delivery attempts, newest first: a gray Held
badge (or amber Deferred for quiet hours) with the resource, a short
reason (Flapping, Acknowledged, Quiet hours, Delivery not turned on,
Monitor-only), and the full explanation as a tooltip. The card answers
"why was nothing sent?" in the same place that shows what was sent —
held rows render even when no delivery was attempted, which is exactly
the silence users misread as breakage.

Held events load independently of the delivery-attempt log and degrade
silently, so an unreadable event log never delays or hides delivery
evidence.

Phase 0 of docs/ALERT_ENGINE_EVOLUTION.md (coverage gap
alert-engine-suppression-observability).
2026-08-26 22:37:30 +01:00
pulse-triage[bot] d15181e960 Govern API token deletion durability
Record durable persistence as the token-revocation commit boundary across API, security, agent-lifecycle, and storage contracts. Route the exact-removal and rollback proofs through the canonical token lifecycle suite.

Change-source: pulse-maintainer
2026-08-26 22:11:28 +01:00
pulse-triage[bot] 9f971b4727 Keep API token deletion atomic
Roll back the in-memory token inventory and return an error when durable persistence fails. Cover exact deletion from a multi-token inventory and the persistence-failure rollback path.

Change-source: pulse-maintainer
2026-08-26 22:01:56 +01:00
pulse-triage[bot] 3f69784454 Restore control-plane revision alignment
Keep status.json.updated_at aligned with the stable SOURCE_OF_TRUTH revision while retaining the newly recorded live alert coverage evidence.

Change-source: pulse-maintainer
2026-08-26 21:33:57 +01:00
pulse-triage[bot] 18bf3e1a8d Complete alert event log governance proof
Bind monitor-side event-log bootstrap to its canonical boundary and exercise the new event infrastructure through the registry-recognized alerts, API, monitoring, and agent-lifecycle proof files.

Change-source: pulse-maintainer
2026-08-26 21:32:10 +01:00
pulse-triage[bot] e88583866a Repair alert delivery governance proof
Bind the delivery diagnosis, active-card presentation, and additive event log to their canonical contracts and recognized API/frontend tests. Sync the shipped API reference, record current browser evidence, and restore sorted truthful control-plane status evidence.

Change-source: pulse-maintainer
2026-08-26 21:29:03 +01:00
rcourtman 2565b82cbe release-control: release alert-engine-suppression-observability work claim
Phase 0 slice landed (bulk delivery diagnosis, card status line, alert
event log + events API).
2026-08-26 21:17:01 +01:00
rcourtman 9572a113ae feat(alerts): append-only alert event log with suppression reasons
Adds internal/alerts/eventlog: a SQLite-backed, additive event log that
records lifecycle transitions (resolved, acknowledged, unacknowledged,
escalated, flapping detected) and notification decisions (dispatched,
deferred by quiet hours, suppressed — with the mechanism that held
them). Appends never block alert evaluation: a full buffer drops the
event and counts the drop; a store that fails to open degrades to
recording nothing. 90-day retention, hourly prune.

The manager emits at the existing funnels only — dispatchAlert and the
safe-call resolve/ack/escalate seams — so no lifecycle behavior
changes. Lifecycle "fired" is deliberately not recorded yet: the
active-alert store funnel also runs on persisted restore, so firing
waits for the explicit activation seam in a later phase. The monitoring
bootstrap enables the log per manager; ephemeral managers and tests
record nothing unless they opt in.

GET /api/alerts/events (monitoring:read) reads the log with
alertIdentifier/type/since/limit filters, newest first.

Phase 0 of docs/ALERT_ENGINE_EVOLUTION.md (coverage gap
alert-engine-suppression-observability).
2026-08-26 21:15:37 +01:00
rcourtman 32e620a6c3 feat(alerts): show notification delivery status on active alert cards
Each active alert card now answers "did this notify, and if not, why
not?" inline: notified time, cooldown with next eligible time, quiet
hours with the replay time, and attention-toned lines for held states
the user may not expect (rate limit, flapping, suppression window,
notifications off / not turned on). Backed by the bulk delivery
diagnosis endpoint — one request per overview refresh, silent degrade
when unavailable. Acknowledged alerts keep their badge and show no
line.

Surfaces the previously unconsumed AlertDeliveryDiagnosis projection
(coverage gap alert-engine-suppression-observability, Phase 0).
2026-08-26 21:05:45 +01:00
rcourtman 515aa319e8 feat(alerts): bulk delivery diagnosis for all active alerts
GET /api/alerts/delivery-diagnosis without alertIdentifier now returns
the diagnosis array for every active alert in one manager pass, so list
surfaces do not need a request per alert. Extracts the per-alert
diagnosis into a locked helper shared by both paths; single-alert
behavior is unchanged.

First slice of coverage gap alert-engine-suppression-observability
(docs/ALERT_ENGINE_EVOLUTION.md Phase 0).
2026-08-26 21:05:37 +01:00
rcourtman 1c4241ad0d docs: scope alert engine evolution and register suppression-observability gap
The March canonical migration froze the transition core and suppression
path; the post-March regression record (#1682, #1683, #1553, #1693) shows
those layers are where the recurring lifecycle bug classes live.
ALERT_ENGINE_EVOLUTION.md extends the migration end-state one layer
deeper — additive event log (Phase 0), shadow reducer (Phase 1),
family-by-family cutover (Phase 2), declarative rules (Phase 3) — using
the same strangler mechanism. Registers the Phase 0 work as coverage gap
alert-engine-suppression-observability with its record.
2026-08-26 20:54:14 +01:00
rcourtman a298a9949a fix: clarify guest and host memory percentages
Contract-Neutral: Updates the browser-verification parent after rebasing the already verified contract-neutral presentation fix onto current main.
2026-08-26 20:28:09 +01:00
pulse-triage[bot] 8fb7b37641 Stabilize release regression tests
Contract-Neutral: Freezes mock sampler cadence only inside the existing cache regression and updates release-preflight assertions to recognize current conditional runner routing and shard-degradation behavior; runtime and public contracts are unchanged.

Change-source: pulse-maintainer
helm-chart-6.4.0-rc.4 v6.4.0-rc.4
2026-08-26 20:22:20 +01:00
rcourtman d2c8973855 Stabilize release preflight scheduling 2026-08-26 20:08:09 +01:00
pulse-triage[bot] a4a26fe842 Preserve availability result delivery order
Change-source: pulse-maintainer
2026-08-26 19:32:17 +01:00
rcourtman 4bca38395a Harden custom sensor test fixture permissions 2026-08-26 19:25:56 +01:00
pulse-triage[bot] 3c4b5c1c9a Record rc4 metadata repair as contract-neutral
Contract-Neutral: Aligns release-note wording with the existing keyed per-client delta contract and its existing regression assertion; no runtime or public-contract behavior changes.

Change-source: pulse-maintainer
2026-08-26 19:19:59 +01:00
pulse-triage[bot] 1625f8a8bd Fix rc4 release metadata contract
Change-source: pulse-maintainer
2026-08-26 19:16:16 +01:00
rcourtman 5194e0ca4d Prepare v6.4.0-rc.4 release 2026-08-26 19:08:28 +01:00
pulse-triage[bot] 1b754d8bfe Document keyed recovery and row identity contracts
Complete the canonical contract fanout for socket-owned delta baselines and independently reconciled logical table rows across alerts, performance, and frontend primitives.

Change-source: pulse-maintainer
2026-08-26 18:54:14 +01:00
pulse-triage[bot] 40f2c12bf4 Preserve keyed rows across snapshot reordering
Keep one independently reconciled store per logical row and reorder stable wrappers. This retains row-local drawer state without allowing nested row reconciliation to duplicate or stale sorted Docker rows.

Change-source: pulse-maintainer
2026-08-26 18:50:08 +01:00
pulse-triage[bot] 795a16fb85 Keep REST recovery out of socket delta baselines
Invalidate every keyed projection when an oversized socket snapshot is dropped. REST recovery may hydrate the display, but infrastructure and alert deltas now wait for a socket-owned baseline and request throttled recovery if one is missing.

Change-source: pulse-maintainer
2026-08-26 18:50:08 +01:00
rcourtman 9e1b8bfa1a Dedupe policy postures, AI-safe summaries, and self-alias ids in the stream
Third increment of the resource-payload-static-metadata gap, the
snapshot-side statics. Measurement first: the mock estate ships only 5
distinct non-default policy postures across 723 resources and 56
distinct templated AI-safe summary strings across the same rows
(~150KB of inline duplication per snapshot), and every canonical alias
list carries the row's own wire id verbatim.

Non-default policies and AI-safe summaries now dedupe through the same
content-addressed catalog contract as capabilities: state-level
policyCatalog and aiSafeSummaryCatalog hold the distinct blobs,
resources carry policyRef / aiSafeSummaryRef, and ingestion expands
refs back to the inline shape (default posture synthesis unchanged for
ref-less rows). The broadcast conversion returns one catalogs struct so
the next deduped field is a loop entry, and catalog changes ride the
same delta frame as the refs that need them. Alias lists stop shipping
the row's own wire id — every identity consumer unions resource.id
beside the alias spread — while the primary id stays so aliases remain
the complete live vocabulary a host is reachable by, per the
established slimming invariant.

Verified against a 1857-resource estate: zero inline policies or
summaries on the wire (743 refs resolving into 1KB + 7KB catalogs),
zero alias lists carrying the wire id, catalog-expanded postures and
summaries reaching the store byte-equivalently, and the estate
rendering clean on desktop and the 36-row phone window.

Remaining gap scope: canonicalIdentity alias/superseded history is
genuine per-resource identity data (~600KB per snapshot) with no safe
derivation shortcut, and the proxmox-facet/platformData mirror
duplication (~200KB) is deliberate canonical-merge fabric; both stay
recorded under resource-payload-static-metadata for a future owner.
2026-08-26 18:46:12 +01:00
rcourtman cba1e2abeb Reconcile delivery health and Proxmox Assistant controls 2026-08-26 18:33:41 +01:00
rcourtman 0fece386c4 Ship active alerts as per-client keyed deltas
Second increment of the resource-payload-static-metadata gap: the full
activeAlerts array (~37-75KB at mock-estate churn) re-shipped whenever
any single alert changed. Alerts now ride the generalized keyed delta
transport: the per-field keying and transition handling in the state
delta engine is a declarative keyedDeltaFields list shared with the
connected-infrastructure projection, and activeAlertsDelta carries
id-keyed merge patches, removed ids, and order. Measured on the mock
estate the per-tick alert payload drops to 184-1981 bytes.

One boundary held deliberately fixed: alert application timing does not
change. The client applies alert deltas to an isolated baseline and
feeds the exact same applyActiveAlerts path immediately on arrival,
input-active or not — alert lifecycle truth never waits for the
operator-input idle gate (alerts subsystem boundary, documented in
6ecdc81d1), and the pending-acknowledgment safeguards see byte-
equivalent records. Alerts handed to the store are cloned so it never
adopts baseline-owned objects. Deltas without a baseline are ignored
and heal on the next full payload; unkeyable entries fall back to
whole-field diffing.

Remaining gap scope unchanged: snapshot-side static metadata
(canonicalIdentity alias history ~609KB per snapshot, and the partially
regressed aiSafeSummary/policy omissions) stays open under
resource-payload-static-metadata.
2026-08-26 18:23:50 +01:00
rcourtman f3d3434652 Ship the infrastructure projection as per-client keyed deltas
First increment of the resource-payload-static-metadata gap: the
connected-infrastructure reporting projection was re-shipped whole
(~55-60KB at 50-node scale) on every realtime broadcast even though
measurement showed the only field that ever changes tick-to-tick is
lastSeen, and the client deep-reconciled all 69 rich items per tick —
the dominant reactive cost inside every websocket message after the
resource merge itself.

The projection now rides the same per-client keyed delta engine as
resources. buildClientStateSnapshot keys it by id beside the resource
map, and buildClientStateDelta emits connectedInfrastructureDelta with
id-keyed JSON merge patches, removed ids, and order through one shared
keyed-array builder. Measured on the mock estate the per-tick payload
drops from ~55-60KB to 0.7-4KB of timestamp patches. Entries that
cannot key by id fall the whole field back to plain whole-payload
diffing, and keyed/unkeyed baseline transitions re-ship the full array
once, so the keyed path can never corrupt the projection.

The client mirrors the resource baseline pattern: full payloads
establish an isolated raw baseline, deltas apply as merge patches
through the now-generic keyed apply helper, and the store sync hands
reconcile reference-stable objects for untouched items so a tick
reconciles only what changed instead of deep-walking the projection.
Deltas without a baseline are ignored and heal on the next full
payload; the operator-input deferral gate carries the pending changed
ids across a gesture and flushes them in the same coalesced batch.

The remaining gap scope (snapshot-side static metadata such as
canonicalIdentity alias history, ~609KB per snapshot) stays open under
resource-payload-static-metadata.
2026-08-26 18:09:34 +01:00
rcourtman 20503086ff Fix Docker history state across filtered refreshes
Contract-Neutral: Behavioral regression fix only; no public API, subsystem boundary, or extension-point contract changes.
2026-08-26 18:06:03 +01:00
pulse-triage[bot] 6ecdc81d1c Preserve live alert truth during input deferral
Document the alert-side ownership boundary for the shared websocket input gate: resource projections may wait for idle, while active and resolved alert lifecycle updates remain immediate.

Change-source: pulse-maintainer
2026-08-26 17:52:36 +01:00
rcourtman 7d34e27b30 Gate realtime tick deferral on all operator input, not just scroll
A tick landing while the operator types in a filter, presses a pointer,
or spins the wheel delayed that interaction's response by the same
200-560ms the scroll path used to pay. The deferral gate now keys on a
shared input-activity window fed by scroll, wheel, pointerdown, and
keydown through one window-level capture registration. Bare pointer
movement deliberately does not gate: a resting hand on the mouse must
not starve data freshness, and the flush recheck still lands deferred
ticks within ~550ms of the last deliberate input.

Verified on the 929-guest mock estate: zero long frames during a 12s
simulated typing burst spanning multiple realtime ticks, one coalesced
flush ~520ms after the last keystroke, and live data continuing to land
on desktop and narrow viewports.
2026-08-26 17:34:11 +01:00
pulse-triage[bot] 99afae02b1 Align windowing guardrail with runway policy
Update the architecture assertion to protect the dead-band runway constant introduced by the large-estate scrolling fix.

Change-source: pulse-maintainer
2026-08-26 17:26:32 +01:00
rcourtman b262f24c54 Defer realtime tick application while the operator scrolls
The remaining scroll hitch on large estates was the realtime websocket
tick: every few seconds a delta landed mid-gesture and blocked the main
thread for 200-560ms. The scroll path itself was already clean after the
windowing fixes, so the tick was the one thing still hitting the wheel.

Mid-gesture ticks now cost ~1ms: the resource delta queues unapplied in
arrival order (even the baseline patch walks the whole estate), and the
reporting projection plus the lastUpdate tick token defer latest-wins
alongside it. Holding the token matters as much as holding the data —
it is what unified resource projections and workload remaps key on, so
deferring it keeps every downstream consumer quiescent through the
gesture. Everything drains as one coalesced batch at scroll idle,
through the same deferral set and flush the hidden-tab path uses.

Ordering and lifecycle guards: a non-empty queue keeps queueing so
deltas never apply out of order, hidden-tab ticks drain the queue before
applying in place, a full snapshot supersedes and clears the queue, and
connection resets drop all pending deferral state. Alert application
stays live mid-gesture.

Verified on the 50-node/929-guest mock estate: zero websocket long
frames across 16-20s continuous scrolls (previously one 200-560ms block
per tick), one coalesced flush ~300-450ms after gesture end, and the
Last refresh footer still advancing on desktop and narrow viewports.

This is a scheduling boundary, not a cost reduction: the per-tick
reconciliation cost itself remains owned by the
resource-payload-static-metadata coverage gap.
2026-08-26 17:18:51 +01:00
rcourtman c154fa7aed Eliminate large-estate scroll hitches in windowed tables
Wheel scrolling the Proxmox overview on a 929-guest estate hitched for
200-260ms per runway rebalance. Four compounding causes, all fixed:

- The windowing runway policy rebalanced in ~53-row jumps inside a
  non-passive wheel listener, so the compositor waited on a multi-frame
  remount. Both windowing owners now keep a symmetric runway topped up
  in dead-band batches (one bounded mutation frame per ~8 rows of
  travel), every windowed-page listener is passive, and only a viewport
  that leaves the mounted window entirely re-centers it in one jump.
- The Workloads viewport-sync effect tracked the windowing signals its
  own measurement pass moves, so every shift re-ran row measurement
  (two forced reflows) and listener binding. The measurement pass is
  now untracked, matching the unified-resource sync owner; the platform
  and storage windowing owners had the same latent tracking and are
  untracked too.
- WorkloadPanel built its guest-id lookup from the windowed slice, so a
  shift re-validated every mounted row's memo chain. The lookup now
  derives from the full group and only changes when data changes.
- The CPU/memory/disk bar hooks read offsetWidth in onMount, forcing a
  full-table reflow per mounted bar during every top-up. Width now
  comes solely from the ResizeObserver's initial pre-paint delivery.

Prewarmed-but-hidden platform tabs also ran viewport sync per scroll
event and paid the visible surface's layout flush; hidden surfaces now
skip sync via a shared checkVisibility guard.

Measured on the 50-node/929-guest mock estate at 2560x1240: a 4-row
top-up fell from ~230ms to ~7ms, scroll-jitter oscillation produces
zero frames over 25ms, and sustained fast scrolling holds native frame
cadence with one bounded mutation frame per dead-band. The remaining
scroll-time long tasks are realtime websocket merge ticks, which the
realtime-merge lane already owns.
2026-08-26 16:07:28 +01:00
pulse-triage[bot] 8d573cd0ac Make formatting-only governance deterministic in CI
Change-source: pulse-maintainer
2026-08-26 16:03:27 +01:00
pulse-triage[bot] 02d6df9317 Fix Proxmox network detail formatting gate
Change-source: pulse-maintainer
2026-08-26 15:57:35 +01:00
pulse-triage[bot] 2db7f8c373 Promote qualified offline-node E2E
Change-source: pulse-maintainer
2026-08-26 15:47:58 +01:00
pulse-triage[bot] 176268ca63 Record Proxmox network browser proof
Change-source: pulse-maintainer
2026-08-26 15:32:23 +01:00
pulse-triage[bot] 75b6655d6e Restore Proxmox node network details
Refs #1716

Change-source: pulse-maintainer
2026-08-26 15:17:12 +01:00
pulse-triage[bot] 9e9c3413a8 Promote qualified E2E specifications
Change-source: pulse-maintainer
2026-08-26 14:27:39 +01:00
rcourtman 74d0895e6e Fix mock storage history continuity
Contract-Neutral: Storage history behavior is documented in the staged API and storage contracts and covered by staged focused regressions; shared router references do not change agent-lifecycle, performance, or security contracts, and the proof allowlists do not yet name the focused test files.
2026-08-26 13:54:55 +01:00