Chengdong ZhangandCursor
6c1357ec4d
Replace mall fixture favorites with customer-scoped endpoints, and send signed-out shoppers back to the page they left after sign-in. Co-authored-by: Cursor <cursoragent@cursor.com>
20 lines
1.4 KiB
Markdown
20 lines
1.4 KiB
Markdown
## ADDED Requirements
|
|
|
|
### Requirement: Live customer favorites
|
|
The mall SHALL use the shared selected API adapter for product and shop favorite state. Product and store detail controls SHALL load persisted state, require customer authentication, prevent duplicate in-flight mutations, and survive reloads. The buyer-center favorites page and dashboard preview/counts SHALL render paginated live favorite results and remove targets through the API instead of reading `MOCK_FAVORITES` or mutating local-only state.
|
|
|
|
#### Scenario: product favorite survives reload
|
|
- **WHEN** a signed-in shopper favorites a product and reloads its detail page
|
|
- **THEN** the favorite control remains selected from backend state
|
|
|
|
#### Scenario: anonymous favorite requires sign-in
|
|
- **WHEN** a signed-out shopper uses a product or store favorite control
|
|
- **THEN** the mall sends the shopper to sign in with the current detail URL as the return destination
|
|
|
|
#### Scenario: remove from buyer center
|
|
- **WHEN** a shopper removes a product or shop from the favorites page
|
|
- **THEN** the API state, visible list, dashboard preview, and visible count reflect the removal without fixture mutation
|
|
|
|
#### Scenario: fixed adapter remains functional
|
|
- **WHEN** the favorites domain is configured to fixed data
|
|
- **THEN** detail controls and buyer-center favorite flows behave deterministically through the same shared client methods |