docs(notification-outbox): fix stale cross-references after outbox addition

docs/requirements/HighLevelReqs.md

@@ -33,7 +33,7 @@
 - **Pre-deployment validation**: Before any deployment is sent to a site, the central cluster performs comprehensive validation including flattening the configuration, test-compiling all scripts, verifying alarm trigger references, verifying script trigger references, and checking data connection binding completeness (see Section 3.11).
 
 ### 1.5 System-Wide Artifact Deployment
-- Changes to shared scripts, external system definitions, database connection definitions, data connection definitions, notification lists, and SMTP configuration are **not automatically propagated** to sites.
+- Changes to shared scripts, external system definitions, database connection definitions, and data connection definitions are **not automatically propagated** to sites. (Notification lists and SMTP configuration are central-only and are not deployed to sites — see Section 6.)
 - Deployment of system-wide artifacts requires **explicit action** by a user with the **Deployment** role.
 - Artifacts can be deployed to **all sites at once** or to an **individual site** (per-site deployment).
 - The Design role manages the definitions; the Deployment role triggers deployment to sites. A user may hold both roles.
@@ -55,7 +55,7 @@
 
 ### 2.3 Site-Level Storage & Interface
 - Sites have **no user interface** — they are headless collectors, forwarders, and script executors.
-- Sites require local storage for: the current deployed (flattened) configurations, deployed scripts, shared scripts, external system definitions, database connection definitions, data connection definitions, notification lists, and SMTP configuration.
+- Sites require local storage for: the current deployed (flattened) configurations, deployed scripts, shared scripts, external system definitions, database connection definitions, and data connection definitions. (Notification lists and SMTP configuration are central-only and are not stored at sites — see Section 6.)
 - After artifact deployment, sites are **fully self-contained** — all runtime configuration is read from local SQLite. Sites do **not** access the central configuration database at runtime.
 - Store-and-forward buffers are persisted to a **local SQLite database on each node** and replicated between nodes via application-level replication (see 1.3).
 
@@ -286,7 +286,7 @@ Scripts **cannot** access other instances' attributes or scripts.
 - Parked messages are **stored at the site** where they originated.
 - The **central UI** can **query sites** for parked messages and manage them remotely.
 - Operators can **retry** or **discard** parked messages from the central UI.
-- Parked message management covers **external system calls**, **notifications**, and **cached database writes**.
+- Parked message management covers **external system calls** and **cached database writes**. (Notifications are not parked at sites — they are store-and-forwarded to central, which owns delivery and parking; see Section 6.)
 
 ### 5.5 Database Connections
 - Database connections are **predefined, named resources** created by users with the **Design** role.
@@ -306,23 +306,23 @@ Scripts can interact with databases in two modes:
 
 ### 6.1 Notification Lists
 - Notification lists are **system-wide**, managed by users with the **Design** role.
-- Each list has a **name** and contains one or more **recipients**.
-- Each recipient has a **name** and an **email address**.
-- Notification lists are deployed to **all sites** (deployment requires explicit action by a user with the Deployment role).
-- At the site, notification lists and recipients are read from **local SQLite** (populated by artifact deployment), not from the central config DB.
+- Each list has a **name** and a **`Type`** (`Email` now; `Teams` and other types planned). The type determines the type-specific targets the list carries.
+- An `Email` list contains one or more **recipients**, each with a **name** and an **email address**.
+- Notification lists are defined and stored **centrally only** — they are **not deployed to sites** and have no local SQLite copy. Recipient resolution happens at central, at delivery time.
 
 ### 6.2 Email Support
 - The system has **predefined support for sending email** as the notification delivery mechanism.
-- Email server configuration (SMTP settings) is defined centrally and deployed to all sites as part of **artifact deployment** (see Section 1.5). Sites read SMTP configuration from **local SQLite**.
+- Email server configuration (SMTP settings) is defined and stored **centrally only**. Sites never talk to SMTP; all delivery happens on the central cluster.
 
 ### 6.3 Script API
 - Scripts send notifications using a simplified API: `Notify.To("list name").Send("subject", "message")`
 - This API is available to instance scripts, alarm on-trigger scripts, and shared scripts.
+- `Send()` generates a `NotificationId` (GUID) locally and returns it to the script immediately; `Notify.Status(notificationId)` returns a status record (status, retry count, last error, key timestamps).
 
-### 6.4 Store-and-Forward for Notifications
-- If the email server is unavailable, notifications are **buffered locally at the site**.
-- Follows the same retry pattern as external system calls: configurable **max retry count** and **time between retries** (fixed interval).
-- After max retries are exhausted, the notification is **parked** for manual review (managed via central UI alongside external system parked messages).
+### 6.4 Notification Delivery and Store-and-Forward
+- Notification delivery is **inverted to the central cluster**. A site script's notification is **store-and-forwarded to central** (target = central, not SMTP); the central **Notification Outbox** logs every notification to a `Notifications` audit table and owns dispatch, delivery, retry, and parking.
+- If the central cluster is unreachable, the notification is **buffered locally at the site** by the Store-and-Forward Engine and retried at a fixed forward interval until central acks it. The site→central forward does not park.
+- Once central holds the notification, delivery retry reuses the central SMTP configuration's **max retry count** and fixed **time between retries**. After retries are exhausted, or on a permanent failure, the notification is **parked** for review on the Central UI Notification Outbox page.
 - There is **no maximum buffer size** for notification messages.
 
 ## 7. Inbound API (Central)
@@ -370,10 +370,11 @@ The central cluster hosts a **configuration and management UI** (no live machine
 - **Site & Data Connection Management**: Define sites (including optional NodeAAddress and NodeBAddress fields for Akka remoting paths, and optional GrpcNodeAAddress and GrpcNodeBAddress fields for gRPC streaming endpoints), manage data connections and assign them to sites.
 - **Area Management**: Define hierarchical area structures per site for organizing instances.
 - **Deployment**: View diffs between deployed and current template-derived configurations, deploy updates to individual instances. Filter instances by area. Pre-deployment validation runs automatically before any deployment is sent.
-- **System-Wide Artifact Deployment**: Explicitly deploy shared scripts, external system definitions, database connection definitions, data connection definitions, notification lists, and SMTP configuration to all sites or to an individual site (requires Deployment role). Per-site deployment is available via the Sites admin page.
+- **System-Wide Artifact Deployment**: Explicitly deploy shared scripts, external system definitions, database connection definitions, and data connection definitions to all sites or to an individual site (requires Deployment role). Per-site deployment is available via the Sites admin page. (Notification lists and SMTP configuration are central-only and are not deployed.)
 - **Deployment Status Monitoring**: Track whether deployments were successfully applied at site level.
 - **Debug View**: On-demand real-time view of a specific instance's tag values and alarm states for troubleshooting (see 8.1).
-- **Parked Message Management**: Query sites for parked messages (external system calls, notifications, and cached database writes), retry or discard them.
+- **Parked Message Management**: Query sites for parked messages (external system calls and cached database writes), retry or discard them.
+- **Notification Outbox**: Monitor centrally-delivered notifications — KPI tiles and a queryable `Notifications` audit list with Retry/Discard actions on parked notifications (see Section 6).
 - **Health Monitoring Dashboard**: View site cluster health, node status, data connection health, script error rates, alarm evaluation errors, and store-and-forward buffer depths (see Section 11).
 - **Site Event Log Viewer**: Query and view operational event logs from site clusters (see Section 12).
 
@@ -422,7 +423,7 @@ All system-modifying actions are logged, including:
 - **Alarm changes**: Create, edit, delete alarm definitions.
 - **Instance changes**: Create, override values, bind connections, area assignment, disable, enable, delete.
 - **Deployments**: Who deployed what to which instance, and the result (success/failure).
-- **System-wide artifact deployments**: Who deployed shared scripts / external system definitions / DB connections / data connections / notification lists / SMTP config, to which site(s), and the result.
+- **System-wide artifact deployments**: Who deployed shared scripts / external system definitions / DB connections / data connections, to which site(s), and the result.
 - **External system definition changes**: Create, edit, delete.
 - **Database connection changes**: Create, edit, delete.
 - **Notification list changes**: Create, edit, delete lists and recipients.
@@ -448,7 +449,8 @@ The central cluster monitors the health of each site cluster, including:
 - **Data connection health**: Connected/disconnected status per data connection at the site.
 - **Script error rates**: Frequency of script failures at the site.
 - **Alarm evaluation errors**: Frequency of alarm evaluation failures at the site.
-- **Store-and-forward buffer depth**: Number of messages currently queued (broken down by external system calls, notifications, and cached database writes).
+- **Store-and-forward buffer depth**: Number of messages currently queued (broken down by external system calls, notifications, and cached database writes). The notification backlog covers the site→central forward leg.
+- **Notification Outbox KPIs**: Central-computed delivery-health metrics — queue depth, stuck count, and parked count — surfaced as headline tiles on the health dashboard. These are computed centrally from the `Notifications` table, not collected from sites.
 
 ### 11.2 Reporting
 - Site clusters **report health metrics to central** periodically.