Files
vmall/openspec/changes/archive/2026-09-24-add-merchant-onboarding/specs/frontend-mall/spec.md
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

2.3 KiB

ADDED Requirements

Requirement: Merchant onboarding multi-step form

The mall SHALL expose a merchant onboarding page ("商家入驻") reachable from the top-bar entry, with a multi-step form covering entity kind (personal 个人 / enterprise 企业), kind-specific entity information, operating categories from the published category tree, contact details, and qualification materials as URL input fields with no file-upload controls. The form SHALL be fillable while signed out, but submission SHALL require registration or sign-in and return the applicant to the completed form to submit through the shared selected API adapter. A duplicate-application conflict SHALL be surfaced inline. All copy SHALL come from the mall locale source in en and zh.

Scenario: anonymous fill then sign-in

  • WHEN a signed-out visitor completes the form and submits
  • THEN they are sent to register or sign in and, once signed in, returned to the completed form to submit

Scenario: enterprise kind shows company fields

  • WHEN the applicant selects the enterprise entity kind
  • THEN the company-specific entity and qualification fields replace the personal ones

Scenario: duplicate application surfaced

  • WHEN a signed-in user holding a pending or approved application submits the form
  • THEN the mall shows the conflict instead of silently creating a second application

Scenario: fixed adapter remains functional

  • WHEN the merchant-onboarding domain is configured to fixed data
  • THEN the form and status flows behave deterministically through the same shared client methods

Requirement: Application status page

The mall SHALL show a signed-in applicant their latest merchant application state — status, submitted entity kind, timestamps, and the rejection reason when rejected — linked from the onboarding page, with a re-apply action after rejection. Anonymous visitors SHALL be sent to sign in first.

Scenario: applicant tracks review

  • WHEN a signed-in applicant opens the status page while the application is pending
  • THEN the pending state and submission summary are shown

Scenario: rejection explains reason

  • WHEN a rejected applicant opens the status page
  • THEN the rejection reason is displayed with an action to apply again