## 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

### Requirement: Multi-notification popup SHALL communicate horizontal navigation

When the homepage notification popup contains more than one notification, the client SHALL make the horizontal swipe interaction visible to the user and SHALL retain the current-position indicator.

#### Scenario: User opens multiple unread notifications

- **WHEN** the homepage popup contains two or more notifications
- **THEN** the popup SHALL display an explicit `左右滑动切换通知` hint
- **AND** the user SHALL be able to move between notifications by swiping horizontally
- **AND** the popup SHALL display the current notification position