52 lines
3.9 KiB
Markdown
52 lines
3.9 KiB
Markdown
## 1. API adapters and shared rules
|
|
|
|
- [x] 1.1 Update asset/auth adapters and login handling for `verify-asset` business failures before asset-token persistence
|
|
- [x] 1.2 Normalize asset response fields for real-name policy/status, allowed payment methods, expiry estimate, and device/card identifiers
|
|
- [x] 1.3 Update order and wallet adapters so every create request includes the selected `payment_method`, and only WeChat requests include `app_type`
|
|
- [x] 1.4 Preserve cent-based request payloads and provide one shared yuan display formatter for amounts
|
|
- [x] 1.5 Confirm notification adapter parameters and response handling against the pending `add-personal-notifications` change
|
|
|
|
## 2. Login and asset state
|
|
|
|
- [x] 2.1 Show the backend business error and stop the current login flow when C-end login is forbidden
|
|
- [x] 2.2 Drive real-name prompts, status labels, and order gates from `effective_realname_policy`, `realname_required`, and `real_name_status`
|
|
- [x] 2.3 Remove local card/device real-name policy inference while preserving the existing real-name link flow
|
|
- [x] 2.4 Replace current-package-only expiry display with `estimated_final_expires_at` and apply backend expiry status/highlight fields
|
|
- [x] 2.5 Gate homepage and operator-switch real-name entries for `after_order` using device card real-name states and pending/active package history
|
|
|
|
## 3. Package purchase and renewal
|
|
|
|
- [x] 3.1 Render payment options from `allowed_payment_methods` on package purchase and prevent unavailable methods from being selected
|
|
- [x] 3.2 Keep discontinued packages out of the ordinary package catalog for new customers and agents
|
|
- [x] 3.3 Add the eligible existing-customer renewal path using `current_package_id` or historical `package_ids`
|
|
- [x] 3.4 Reuse `POST /api/c/v1/orders/create` for renewal and preserve selected identifier, package IDs, payment method, and existing payment result handling
|
|
- [x] 3.5 Show `立即续费` only on the homepage asset summary and every order-list card, with direct order/payment handling
|
|
|
|
## 4. Wallet recharge and payment completion
|
|
|
|
- [x] 4.1 Call `/api/c/v1/wallet/recharge-check` before recharge and enforce backend force-recharge/min/max guidance in the UI
|
|
- [x] 4.2 Render recharge payment methods from the recharge-check response and submit the selected method
|
|
- [x] 4.3 Preserve existing WeChat `pay_config`, Alipay/other `payment_link`, wallet payment, and submit-guard behaviors
|
|
- [x] 4.4 Refresh and confirm order/recharge status from the backend after payment return or link completion
|
|
|
|
## 5. Customer notifications
|
|
|
|
- [x] 5.1 Refresh unread count at the homepage or notification entry using `/api/c/v1/notifications/unread-count`
|
|
- [x] 5.2 Display expiry and exchange notifications from `/api/c/v1/notifications`, including backend severity/expiry level
|
|
- [x] 5.3 Mark an item read with `/api/c/v1/notifications/{id}/read` when the user views or activates it, then reconcile the unread badge
|
|
- [x] 5.4 Keep notification failures non-blocking for asset loading and do not add WeCom, marketing, or ERP calls
|
|
|
|
## 6. Order display
|
|
|
|
- [x] 6.1 Render `purchase_role` from order list/detail responses
|
|
- [x] 6.2 Render `asset_identifier` snapshots, using device `virtual_no` first and `imei` second, never SN as a substitute
|
|
- [x] 6.3 Preserve blank historical data as an empty-state placeholder and format order amounts from cents to yuan
|
|
|
|
## 7. Verification
|
|
|
|
- [ ] 7.1 Add or update tests for login denial, all real-name policies, backend payment-method variations, and WeChat `app_type`
|
|
- [ ] 7.2 Add or update tests for force recharge, discontinued-package renewal, expiry estimate states, notification priority/read flow, and order identifier fallback
|
|
- [x] 7.3 Run the H5 compiler build and repository consistency checks; manual API fixture verification remains an integration follow-up
|
|
|
|
> Note: This H5 repository has no test script or test suite. Tasks 7.1 and 7.2 remain unchecked and require adding a test harness or backend/API fixture environment before they can be completed.
|