james
9904696e76
Implements, verifies, and archives the three remaining Wave 2 changes from openspec/MIGRATION-PLAN.md. - add-wallet-settlement (P3): demo recharge, guarded withdrawal freeze and one-time admin review, paginated own fund entries, idempotent per-shop weekly/monthly settlement statements with commission rate and one-time payout confirmation. - add-merchant-onboarding (P5): personal/enterprise applications with one live application per user, guarded review with mandatory rejection reason, and transactional shop + owner provisioning returning one-time credentials; mall onboarding/status pages and an admin review console. - add-membership-messaging (P7): platform member levels, append-only growth accrual on order completion with guarded one-way leveling, order/shipment/ refund system messages with unread/read state and soft deletion, plus the mall header unread badge. Backend: migrations 0019-0023, new wallet, settlement, merchant_onboarding, membership and messaging modules, event hooks in order/fulfillment/aftersale, and integration suites for each. Shared contract extended and all three frontends updated; code indexes, domain docs, backend guidelines and the migration tracker synced. Verification: cargo test -p vmall-api green twice consecutively; mall, admin and shop-admin builds pass; browser smoke on every new surface; openspec validate --all --strict green (33 passed). The three changes share the @vmall/shared contract, the mall mock adapter and per-app locale/nav files, so they are committed together to keep every commit buildable.
20 lines
1.4 KiB
Markdown
20 lines
1.4 KiB
Markdown
## ADDED Requirements
|
|
|
|
### Requirement: Member level management
|
|
Platform admins SHALL manage member levels from a dedicated admin console page through the shared API contract: levels listed in growth-threshold order, and create, edit, and delete actions over name, icon, growth threshold, and benefits with both locales editable. Deleting a level in use SHALL surface the API rejection instead of silently succeeding, and member-level management SHALL be reachable from the authenticated console navigation beside existing platform operations.
|
|
|
|
#### Scenario: manage a member level
|
|
- **WHEN** a platform admin creates a level with bilingual name and benefits, an icon, and a growth threshold
|
|
- **THEN** it appears in threshold order and is available for automatic leveling
|
|
|
|
#### Scenario: edit a growth threshold
|
|
- **WHEN** a platform admin changes a level's growth threshold to a unique value
|
|
- **THEN** the level persists with the new threshold and the bilingual content unchanged
|
|
|
|
#### Scenario: deleting a level in use fails visibly
|
|
- **WHEN** a platform admin deletes a level that customers hold
|
|
- **THEN** the console surfaces the rejection and the level and its members remain unchanged
|
|
|
|
#### Scenario: level management appears in admin navigation
|
|
- **WHEN** an authenticated platform admin opens the admin console
|
|
- **THEN** member-level management is reachable from the console nav |