# Preserve the status baseline across a notification memo reset · lucenx/codexbar-plasma

[View on GitCafe](https://git.cafe/lucenx/codexbar-plasma/commit/9f7e5d787c0b7cfa686a1d9ded69a7685df4a82a)

Repository: [lucenx/codexbar-plasma](https://git.cafe/lucenx/codexbar-plasma)

Visibility: public

Requested revision: 9f7e5d787c0b7cfa686a1d9ded69a7685df4a82a

Requested commit: 9f7e5d787c0b7cfa686a1d9ded69a7685df4a82a

Commit: 9f7e5d787c0b7cfa686a1d9ded69a7685df4a82a

Tree: 98ceef00cefda2f1c15138d1c960d0a7caa86768

Author: Simone

Committer: Simone

## Message

```
Preserve the status baseline across a notification memo reset

Silently priming the first observation of a skipped provider fixed the
duplicate alert but introduced the opposite fault: an incident that began
or worsened while the provider was still refreshing became the baseline
and never notified.

The root cause is that resetNotificationMemo dropped provider status along
with the threshold-derived state, even though a settings change is not a
status transition. Status keys now survive the reset, and primeNotifications
carries an existing baseline across a provider it skips. Silent priming is
therefore limited to a genuine first observation, where no prior knowledge
exists.

Behaviour by scenario, given a threshold change during a pending refresh:
an unchanged ongoing incident stays quiet, an incident that starts or
worsens during the interval notifies through the existing worsened and
incidentChanged paths, and a cold start with no baseline primes silently.

Both invariants get static assertions, verified to fail when the reset
wipes the whole memo and when the carry-forward is removed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

```

## Parents

- [6ba10ff31063383fbffb0fee68a957301d631f53](https://git.cafe/lucenx/codexbar-plasma/commit/6ba10ff31063383fbffb0fee68a957301d631f53?format=markdown)

[Source at this commit](https://git.cafe/lucenx/codexbar-plasma/tree/9f7e5d787c0b7cfa686a1d9ded69a7685df4a82a?format=markdown)