32 lines
2.3 KiB
Markdown
32 lines
2.3 KiB
Markdown
## 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
|