vmall/openspec/changes/add-membership-messaging/specs/frontend-mall/spec.md

ADDED Requirements

Requirement: Member center level page

The buyer center SHALL render a membership level page from the selected API adapter: the current level's name, icon, and benefits, the total growth value, progress toward the next level's threshold, and the customer's growth history from the growth ledger. The page SHALL NOT derive level state from fixtures or local state, and it SHALL behave deterministically when the membership domain is configured to fixed data.

Scenario: level page reflects backend state

• WHEN a signed-in shopper whose growth qualifies for a level opens the member-center level page
• THEN the current level, benefits, growth total, and remaining growth to the next level render from the adapter without per-entry requests

Scenario: growth history lists ledger entries

• WHEN a shopper opens the level page
• THEN recent growth ledger entries with delta, reason, and time render paginated from the adapter

Scenario: fixed adapter remains functional

• WHEN the membership domain is configured to fixed data
• THEN the level page renders deterministic fixed level and growth data through the same shared client methods

Requirement: Message center

The mall SHALL render a user message center from the selected API adapter with a paginated message list and an unread-only filter. Opening or explicitly marking a message read, marking all read, and deleting a message SHALL persist through the API and update the visible list and counts without local-only mutation. Each message SHALL render its title and body in the active locale from the shared bilingual contract. Listing and refresh SHALL happen on entry and on demand; no push transport is required.

Scenario: unread filter and marking

• WHEN a shopper filters the message center to unread and marks one message read
• THEN the message persists as read and leaves the unread-only view with the unread count reduced

Scenario: mark all read

• WHEN a shopper uses mark-all-read in the message center
• THEN every unread message becomes read and the unread-only view empties

Scenario: delete a message

• WHEN a shopper deletes a message
• THEN it disappears from the list and the unread count through the API state

Scenario: fixed adapter remains functional

• WHEN the messaging domain is configured to fixed data
• THEN message listing, read marking, mark-all-read, and deletion behave deterministically through the same shared client methods

Requirement: Top-bar unread badge

The mall shell SHALL show the authenticated customer's unread message count as a badge on its message entry, read from the shared unread-count contract. The badge SHALL refresh on page entry and after read, mark-all-read, and delete actions, and SHALL be absent for anonymous shoppers.

Scenario: badge reflects unread count

• WHEN a signed-in shopper with three unread messages loads any mall page
• THEN the message entry badge shows three

Scenario: badge clears after mark-all-read

• WHEN a shopper marks all messages read and returns to the shell
• THEN the badge shows no unread count