21 lines
1.4 KiB
Markdown
21 lines
1.4 KiB
Markdown
## ADDED Requirements
|
|
|
|
### Requirement: Buyer wallet surface
|
|
The mall SHALL render a buyer-center wallet page driven by the selected API adapter through `@vmall/shared`: available and frozen balance with currency, paginated fund entries, a clearly labeled demo recharge form, and a withdrawal request form. Balances and entries SHALL reflect backend state after each action rather than local-only state. The wallet SHALL be a mall API domain with fixed-adapter fallback methods and `LIVE_PICKS` wiring following the established per-domain adapter pattern.
|
|
|
|
#### Scenario: wallet page loads live state
|
|
- **WHEN** a signed-in buyer opens the wallet page
|
|
- **THEN** balances and the first page of fund entries render from the shared wallet contract
|
|
|
|
#### Scenario: demo recharge updates balance
|
|
- **WHEN** the buyer submits a demo recharge
|
|
- **THEN** the visible available balance reflects the credit without a reload and the form is visibly marked simulated
|
|
|
|
#### Scenario: withdrawal freezes visibly
|
|
- **WHEN** the buyer submits a withdrawal request
|
|
- **THEN** the visible summary shows available decreased and frozen increased by the requested amount, and the request appears in the withdrawal list as pending
|
|
|
|
#### Scenario: fixed adapter remains functional
|
|
- **WHEN** the wallet domain is configured to fixed data
|
|
- **THEN** the wallet page behaves deterministically through the same shared client methods
|