[nofuturekid]

What changed

First pull request of alerts outside the app (design on #321). It adds only the pure decision logic and its stored state. Nothing runs in the background yet.

• evaluateAlerts (data/alerts/AlertRules.kt): given what one check of one server returned and the remembered state of that server, it returns the alerts to post now and the next state.
  • Each new unread notification of importance alert or warning is posted once per id, never twice (also not after it left the unread list). A later notification with the same text has a new id and is posted.
  • The array conditions "not started" and "degraded" are the rules of attentionItems, wrapped and limited to those two keys (not forked, not changed). They are posted when they begin and again only after they were gone at an in-between check.
  • The first successful read of a server only records what is already there and posts nothing. A failed or unreachable read changes nothing and posts nothing, and does not count as the first read.
  • The level filters: "Alerts only" posts critical items (alert notifications, degraded array); "Alerts and warnings" also posts warnings (warning notifications, array not started). Filtered items are still remembered.
  • At most 5 alerts per server and check get their own notification, most urgent first; the rest are counted for a summary line ("and 3 more on Tower").
  • The remembered ids are capped at 300; ids still on the server are never forgotten before ids that are gone.
• State store (AlertStateStore, ServerAlertState): one small interface, persisted in the existing DataStore under a new key at the end of SettingsStore (JSON per server id), with get, put, remove and clear. ServerRepository.delete removes the server's state next to its key and pin.
• One-shot seam (ServerProbe, ProbeResult): the interface for "fetch what one check needs from one server once". No implementation; only a test fake. The server-facing implementation arrives with the worker.
• ADR-0048 (opt-in background alert checks) records the decision of 2026-11-13, the rules above and their trade-offs. ADR-0017 gets a dated amendment line (the foreground-only rule stays; the opt-in job is the one exception), and the ADR index has the new row. 0048 is used because 0047 is taken by another change in flight.

Why

Users want to know about a failing disk or an array that is not started without opening NOVA. Getting the rules and the memory right first, with tests, means the worker, the settings screen and a later widget only have to use them.

Tests

New unit tests under app/src/test/.../data/alerts/, each stating why it exists:

• AlertRulesTest (26): first check seeds silently; one alert per notification id; level filter; array condition once per episode; unreachable server is silent and keeps its memory; each failed half keeps its state; flood cap; the id list stays bounded; STATE_ALERT_KEYS is exactly the two array keys (disk and temperature items are not posted again).
• AlertCheckCycleTest (6): whole checks over several rounds and two servers on the in-memory fakes: state is per server, removed with the server, cleared when alerts are switched off, and bounded.
• AlertStateStoreTest (7, Robolectric, real DataStore): state survives a new store object over the same file, servers do not share state, deleting a server entry removes its state.

./scripts/local-ci.sh passes (lint, debug and release builds of both flavors, unit tests).

Deliberately left out

No background work, no WorkManager dependency, no permission, no notification channel, no settings UI, no real server query, no CHANGELOG entry (nothing is user-visible yet), no version bump, no documentation for users. The capability model, the Docker, VMs and Array tabs, the update code, the manifest, build files and .github/ are untouched. The last-check record and the address order of the design's later changes are not here either.

Refs #321

🤖 Generated with Claude Code