vmall/openspec/changes/archive/2026-09-25-add-membership-messaging/specs/frontend-admin/spec.md at 9904696e76a897fb7a39b0a94a198320c93973ec

Files

T

james 9904696e76 feat: wave 2 migration (P3, P5, P7 openspec changes)

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.

2026-09-25 15:25:29 +00:00

1.4 KiB

Raw Blame History

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

WHEN an authenticated platform admin opens the admin console
THEN member-level management is reachable from the console nav

1.4 KiB Raw Blame History