## Purpose

Provide a persistent personal notification inbox shared by the Notifications page and the header, with consistent read and deletion state.

## ADDED Requirements

### Requirement: Personal access
The system SHALL require an authenticated active user and scope all notification operations to that user's recipient records. Missing and unowned ids SHALL return 404 without exposing recipient information.

#### Scenario: Another user's notification
- **WHEN** a user requests, reads, deletes or restores a notification they do not own
- **THEN** the API returns 404 and changes no recipient state

#### Scenario: Anonymous request
- **WHEN** an unauthenticated visitor requests the inbox
- **THEN** the API returns 401

### Requirement: Filtered stable feed
The system SHALL return nondeleted personal notifications ordered by creation timestamp descending then id descending, supporting pagination, message/reference search, category, read status and inclusive date filters in the configured system timezone.

#### Scenario: Date range and pagination
- **WHEN** a valid date range is submitted
- **THEN** both boundary dates are included using the system timezone, pagination describes the filtered total, and tied timestamps have deterministic ordering

#### Scenario: Invalid filter
- **WHEN** an impossible date, reversed range or unsupported enum is submitted
- **THEN** the API returns a validation error

### Requirement: Calibration exclusion
The system SHALL exclude CALIBRATION_DUE and notifications linked to calibration work orders from list, detail, summary and export without deleting historical records.

#### Scenario: Legacy calibration record
- **WHEN** a recipient has a calibration notification
- **THEN** it is absent from the feed and unread count and cannot be opened through the inbox detail endpoint

### Requirement: Explicit read acknowledgement
Opening a list, header or detail SHALL NOT mark notifications read. Explicit read SHALL preserve the first read timestamp. Read-all SHALL acknowledge the user's currently visible unread records through the server request cutoff, independent of page filters.

#### Scenario: Read-all on filtered page
- **WHEN** the user marks all read while filtering warnings
- **THEN** eligible system notifications are also read, other users are unaffected, and later notifications remain unread

### Requirement: Personal deletion and undo
Deletion SHALL hide only the current recipient's entry. Restore SHALL preserve its previous read state. Repeated read, delete and restore requests SHALL be safe.

#### Scenario: Undo deletion
- **WHEN** a user deletes and restores a read notification
- **THEN** it returns in timestamp order as read and other recipients' entries remain unchanged

### Requirement: Filtered export
The system SHALL export all matching visible personal notifications rather than only the current page, preserving CSV escaping and protecting spreadsheet formulas. Exports exceeding 10,000 rows SHALL return an explicit validation error without silent truncation.

#### Scenario: Multiple filtered pages
- **WHEN** a user exports a result containing multiple pages below the limit
- **THEN** the CSV includes all matching rows and no other user's records

### Requirement: Three latest header notifications
The header SHALL show at most three newest visible personal notifications, including read records. Its unread badge SHALL count all visible unread records. Lihat semua SHALL open the Notifications page, and selecting an item SHALL open its existing detail there.

#### Scenario: More than three unread entries
- **WHEN** the user has seven unread visible notifications
- **THEN** the header shows the newest three and an unread count of seven, and opening it does not clear that count

#### Scenario: Fewer than three entries
- **WHEN** the user has two visible entries
- **THEN** the header shows those two without dummy placeholders

### Requirement: Consistent consumer state
The page SHALL preserve existing filters, table columns, pagination, detail and actions while using persistent data. Both consumers SHALL provide loading, empty and failure feedback, synchronize after mutations, and refresh every 60 seconds while visible and authenticated and on focus. Account changes SHALL NOT expose previous-user cached data.

#### Scenario: Page action affects header
- **WHEN** the user marks a notification read or deletes it on the page
- **THEN** the header refreshes its rows and unread count to the same persisted state

#### Scenario: Request failure or account switch
- **WHEN** a request fails or another user signs in
- **THEN** the consumer does not substitute dummy data or show the previous account's notifications