feat: new

openspec/changes/update-phone-bind-association-flow/specs/index-phone-bind-gate/spec.md

@@ -0,0 +1,23 @@
+## MODIFIED Requirements
+
+### Requirement: Index entry SHALL enforce the bind-phone gate from the asset association state
+The system SHALL determine whether phone-verification guidance is required whenever the homepage is entered, using the current asset association state returned by `GET /api/c/v1/asset/info` -> `bound_phone` (empty means the asset is not associated and binding is required). The widened `need_bind_phone` decision stays wechat-login-only: no main phone -> required; main phone exists but the current asset is unassociated -> required; already associated -> not required; global switch off -> never required. The frontend still uses the signal only to decide whether to guide the user, and the backend does not block any business interface on the missing relation.
+
+#### Scenario: User has no main phone
+- **WHEN** the account has no main phone and the user enters `pages/index/index`
+- **THEN** the system SHALL treat phone verification as required
+- **AND** the system SHALL route the user into the bind-phone guide
+
+#### Scenario: User has a main phone but the current asset is unassociated
+- **WHEN** the account has a main phone but the current asset is not associated with it
+- **THEN** the system SHALL treat phone verification as required
+- **AND** the bind page SHALL prefill the account main phone from `asset/info.bound_phone`
+
+#### Scenario: User is already associated
+- **WHEN** the current asset is already associated with the account main phone
+- **THEN** the system SHALL keep the user on the homepage
+- **AND** the system SHALL NOT route the user into the bind-phone guide
+
+#### Scenario: Global switch off
+- **WHEN** the global phone-bind switch is off
+- **THEN** the system SHALL never route the user into the bind-phone guide regardless of account state

openspec/changes/update-phone-bind-association-flow/specs/phone-bind-association-prefill/spec.md

@@ -0,0 +1,36 @@
+## ADDED Requirements
+
+### Requirement: Bind page SHALL prefill the account main phone
+The system SHALL prefill the bind-phone input with the logged-in account's main phone when one exists, using `GET /api/c/v1/asset/info` -> `bound_phone`, and SHALL allow sending a `bind_phone` verification code to that number.
+
+#### Scenario: Existing account with a main phone enters the bind page
+- **WHEN** the account already has a main phone and the user enters `pages/bind/bind`
+- **THEN** the phone input SHALL be prefilled with the main phone
+- **AND** the user SHALL be able to request a `bind_phone` verification code for that number without being rejected
+
+#### Scenario: New account without a main phone enters the bind page
+- **WHEN** the account has no main phone
+- **THEN** the phone input SHALL remain empty
+- **AND** the user SHALL enter a new number and follow the normal bind flow
+
+### Requirement: Bind submission SHALL be idempotent for the account main phone
+When `POST /api/c/v1/auth/bind-phone` is submitted with the account main phone and a valid code, the system SHALL treat it as a successful idempotent association instead of rejecting because the phone is already in use.
+
+#### Scenario: Main phone plus valid code
+- **WHEN** the submitted phone equals the account main phone and the code is valid
+- **THEN** the bind request SHALL succeed
+- **AND** the response SHALL keep the existing shape (`phone`, `bound_at`)
+- **AND** the existing bind-completion routing SHALL apply unchanged
+
+#### Scenario: Number different from the main phone
+- **WHEN** the submitted phone differs from the account main phone
+- **THEN** the bind request SHALL be rejected
+- **AND** the system SHALL display the backend `msg` and keep the user on the bind page
+
+### Requirement: Bind failures SHALL display backend messages
+The system SHALL present the backend-provided error message for all bind-phone failures instead of a generic failure text, and SHALL keep the user on the bind page.
+
+#### Scenario: Backend rejection with message
+- **WHEN** `bind-phone` returns a business error
+- **THEN** the bind page SHALL show the returned `msg`
+- **AND** the page SHALL NOT navigate away

openspec/changes/update-phone-bind-association-flow/specs/phone-change-migration/spec.md

@@ -0,0 +1,29 @@
+## ADDED Requirements
+
+### Requirement: Change-phone SHALL follow transactional full migration
+The system SHALL rely on `POST /api/c/v1/auth/change-phone` to migrate all valid phone-asset associations in one transaction, and SHALL treat any failure as a rollback of the whole operation.
+
+#### Scenario: Successful migration
+- **WHEN** the old-phone code and the new-phone code are valid and no limit or conflict occurs
+- **THEN** the change request SHALL succeed
+- **AND** the response SHALL keep the existing shape (`phone`, `changed_at`)
+- **AND** the user SHALL return to the previous page and the homepage SHALL refresh the bound state
+
+#### Scenario: New number exceeds the association limit
+- **WHEN** the new number would exceed 10 valid associated assets
+- **THEN** the whole operation SHALL be rolled back
+- **AND** the system SHALL display the backend copy: 该手机号最多关联10项有效资产
+
+#### Scenario: New number conflicts with an existing same-asset relation
+- **WHEN** the new number already has a valid association with an asset being migrated
+- **THEN** the whole operation SHALL be rolled back
+- **AND** the system SHALL display the backend copy: 新手机号已存在与待迁移资产相同的有效关联，换绑已回滚
+
+### Requirement: Change-phone failures SHALL keep the user on the page
+The system SHALL stay on the change-phone page and show the backend error message when migration fails so the user can correct the input and retry.
+
+#### Scenario: Migration failure with message
+- **WHEN** `change-phone` returns a business error
+- **THEN** the page SHALL show the returned `msg`
+- **AND** the page SHALL NOT navigate away
+