## ADDED Requirements

### Requirement: H5/C SHALL surface unread customer notifications

The H5/C client SHALL use `GET /api/c/v1/notifications/unread-count` for the homepage or notification-entry badge and `GET /api/c/v1/notifications` for the notification list. It SHALL consume the existing personal-notification contract and SHALL not add a separate API for expiry or exchange reminders.

#### Scenario: Unread notifications exist

- **WHEN** the unread-count endpoint returns a positive count
- **THEN** the homepage or notification entry SHALL display the unread indicator using that count
- **AND** the notification list entry SHALL remain available

#### Scenario: No unread notifications exist

- **WHEN** the unread-count endpoint returns zero
- **THEN** the client SHALL clear the unread indicator
- **AND** the notification entry SHALL not show a stale count

### Requirement: Expiry and exchange notices SHALL use the shared notification channel

The client SHALL display package-expiry and exchange-related notifications returned for the authenticated customer through the shared notification list or reminder popup. The backend notification data SHALL determine the expiry trigger and severity; the client SHALL not create independent timers that send business notifications.

#### Scenario: Package reaches a reminder threshold

- **WHEN** the notification service returns an unread package-expiry notice for the 15-day, 7-day, or 3-day threshold
- **THEN** the client SHALL display it through the existing H5/C notification entry or popup
- **AND** the client SHALL use the returned expiry level for presentation

#### Scenario: Critical expiry notice has highest priority

- **WHEN** unread expiry notices include a notice for 0 to 3 remaining days
- **THEN** the client SHALL give that notice the highest reminder priority
- **AND** the client SHALL not downgrade it based on a client-side date calculation

#### Scenario: Exchange notification is returned

- **WHEN** an exchange-related unread notice is returned after an exchange is created
- **THEN** the notification entry/list SHALL display the notice
- **AND** the client SHALL not call a separate marketing, ERP, or salesperson notification endpoint

### Requirement: Viewing a notification SHALL support marking it read

When the user views or activates a notification, the client SHALL call `PUT /api/c/v1/notifications/{id}/read` for that notification and reconcile the local unread count after a successful response. Repeated read actions SHALL remain safe according to the existing notification API contract.

#### Scenario: User reads an unread notice

- **WHEN** the user opens or advances to an unread expiry or exchange notification
- **THEN** the client SHALL mark that notification read through the existing endpoint
- **AND** the badge/list state SHALL reflect the read result

#### Scenario: Notification read request fails

- **WHEN** marking a notification read fails
- **THEN** the client SHALL retain the unread state or refresh it from the backend
- **AND** the failure SHALL not prevent the user from viewing other asset or notification content