docs(openspec): propose 8 tigshop migration changes (P0-P7) + migration plan
This commit is contained in:
Chengdong Zhang
@@ -0,0 +1,20 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Merchant application review console
|
||||
Platform admins SHALL review merchant onboarding applications in a dedicated console entry beside existing platform operations: a status-filtered paginated list and a detail view showing entity kind, entity information, operating categories, contact details, and qualification URL fields. Approving SHALL provision the shop and `shop_owner` account and display the one-time initial credentials exactly once, with copy stating the password cannot be retrieved again. Rejecting SHALL require a reason. Reviewed applications SHALL leave the pending queue immediately.
|
||||
|
||||
#### Scenario: review an enterprise application
|
||||
- **WHEN** a platform admin opens a pending enterprise application
|
||||
- **THEN** the company entity data, operating categories, contact details, and qualification URLs are visible for review
|
||||
|
||||
#### Scenario: approve shows one-time credentials
|
||||
- **WHEN** a platform admin approves an application
|
||||
- **THEN** the created shop owner's initial credentials are shown once and the application moves to the approved list
|
||||
|
||||
#### Scenario: reject requires a reason
|
||||
- **WHEN** a platform admin attempts to reject without entering a reason
|
||||
- **THEN** the action is blocked until a non-empty reason is provided
|
||||
|
||||
#### Scenario: entry beside platform operations
|
||||
- **WHEN** an authenticated platform admin opens the admin console
|
||||
- **THEN** merchant application review is reachable from the console navigation
|
||||
@@ -0,0 +1,31 @@
|
||||
## 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
|
||||
@@ -0,0 +1,68 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Merchant application submission
|
||||
A prospective seller SHALL submit one merchant onboarding application as either a personal (个人) or an enterprise (企业) entity. Each kind SHALL require its own entity information, one or more operating categories referenced from the published category tree, contact details, and qualification materials submitted as URL fields. The API MUST reject submissions with missing kind-specific fields, unknown categories, or malformed qualification URLs. The form MAY be filled anonymously, but submission SHALL require an authenticated user.
|
||||
|
||||
#### Scenario: enterprise submission accepted
|
||||
- **WHEN** an authenticated user submits an enterprise application with entity information, operating categories, contact details, and qualification URLs
|
||||
- **THEN** the application is stored with status `pending` and returned to the applicant
|
||||
|
||||
#### Scenario: personal submission missing identity document
|
||||
- **WHEN** a user submits a personal application without the required identity document URL
|
||||
- **THEN** the API returns a validation error and stores no application row
|
||||
|
||||
#### Scenario: anonymous submit requires sign-in
|
||||
- **WHEN** a signed-out visitor submits the completed form
|
||||
- **THEN** no application is stored and the visitor must register or sign in before submitting
|
||||
|
||||
### Requirement: One active application per user
|
||||
Submission SHALL be deduplicated per user: a user holding a `pending` or `approved` application MUST NOT create another one, enforced by service validation backed by a database partial unique index so concurrent submissions cannot both succeed. A user whose application was `rejected` MAY apply again.
|
||||
|
||||
#### Scenario: duplicate pending submission
|
||||
- **WHEN** a user with a `pending` application submits again
|
||||
- **THEN** the API rejects the request with a conflict and exactly one application row exists
|
||||
|
||||
#### Scenario: re-apply after rejection
|
||||
- **WHEN** a user whose application was `rejected` submits a new application
|
||||
- **THEN** a new `pending` application row is created
|
||||
|
||||
### Requirement: Review state machine
|
||||
An application SHALL move only from `pending` to `approved` or `rejected`, executed as guarded updates matching the `pending` state so concurrent or repeated reviews of the same application fail with a conflict instead of overwriting each other. Rejecting SHALL require a non-empty reason recorded on the row, and `approved` and `rejected` are terminal states that MUST NOT transition again.
|
||||
|
||||
#### Scenario: double review conflict
|
||||
- **WHEN** two platform admins review the same `pending` application concurrently
|
||||
- **THEN** exactly one transition succeeds and the other receives a conflict
|
||||
|
||||
#### Scenario: rejection records a reason
|
||||
- **WHEN** a platform admin rejects a `pending` application with a reason
|
||||
- **THEN** the application becomes `rejected` with the reason stored on the row
|
||||
|
||||
#### Scenario: terminal state is immutable
|
||||
- **WHEN** a platform admin reviews an already `approved` or `rejected` application
|
||||
- **THEN** the API returns a conflict and the stored state is unchanged
|
||||
|
||||
### Requirement: Transactional approval provisioning
|
||||
Approving an application SHALL, within a single database transaction, create the shop, create a dedicated `shop_owner` account scoped to that shop, and mark the application `approved` referencing the created shop. The generated initial password SHALL be returned exactly once in the approve response and MUST NOT be retrievable through any later read. If any step fails, the status change and all provisioning SHALL roll back so the application remains `pending`.
|
||||
|
||||
#### Scenario: approval provisions shop and account
|
||||
- **WHEN** a platform admin approves a `pending` application
|
||||
- **THEN** one transaction results in an `approved` application, an active shop, and a working `shop_owner` login scoped to that shop
|
||||
|
||||
#### Scenario: credentials shown once
|
||||
- **WHEN** the approver reads the application again after approval
|
||||
- **THEN** the initial password is absent from every subsequent response
|
||||
|
||||
#### Scenario: provisioning failure rolls back
|
||||
- **WHEN** shop or account creation fails during approval
|
||||
- **THEN** no shop or account persists and the application remains `pending`
|
||||
|
||||
### Requirement: Application visibility
|
||||
An applicant SHALL read only their own application history, including status, submitted data, timestamps, and rejection reason. Platform admins SHALL list all applications with status filtering and pagination and read any application detail. Other users' applications MUST NOT be readable through customer routes.
|
||||
|
||||
#### Scenario: applicant checks status
|
||||
- **WHEN** a signed-in applicant requests their application status
|
||||
- **THEN** their own application state and rejection reason are returned
|
||||
|
||||
#### Scenario: other applicant is hidden
|
||||
- **WHEN** one authenticated user requests another user's application through customer routes
|
||||
- **THEN** the API returns no data about the other user's application
|
||||
Reference in New Issue
Block a user