feat: 7月迭代

openspec/changes/update-july-h5-c-iteration/specs/c-notification-reminders/spec.md

@@ -0,0 +1,55 @@
+## 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