device-voice-h5/openspec/changes/add-payment-submit-guard/specs/payment-submit-guard/spec.md

ADDED Requirements

Requirement: Wallet recharge confirmation SHALL prevent duplicate submission

The system SHALL prevent repeated taps on the wallet recharge confirmation button from starting more than one recharge submission flow at the same time.

Scenario: User taps confirm recharge repeatedly during submission

• WHEN the user taps the wallet recharge confirmation button multiple times before the current confirmRecharge flow completes
• THEN the system SHALL execute only the first submission flow
• AND the system SHALL ignore subsequent taps until the current flow ends

Scenario: Wallet recharge confirmation enters submitting state

• WHEN the first valid wallet recharge confirmation tap is accepted
• THEN the system SHALL mark the wallet recharge confirmation flow as submitting immediately
• AND the system SHALL present the confirmation button as non-repeatable during that state

Scenario: Wallet recharge confirmation recovers after terminal outcome

• WHEN the wallet recharge flow ends because of success, failure, cancellation, local validation failure, or modal re-entry
• THEN the system SHALL clear the submitting state
• AND the user SHALL be able to start a new recharge attempt

Requirement: Package payment confirmation SHALL prevent duplicate submission

The system SHALL prevent repeated taps on the package payment confirmation button from starting more than one package payment submission flow at the same time.

Scenario: User taps confirm payment repeatedly during submission

• WHEN the user taps the package payment confirmation button multiple times before the current confirmPay flow completes
• THEN the system SHALL execute only the first submission flow
• AND the system SHALL ignore subsequent taps until the current flow ends

Scenario: Package payment confirmation enters submitting state

• WHEN the first valid package payment confirmation tap is accepted
• THEN the system SHALL mark the package payment confirmation flow as submitting immediately
• AND the system SHALL present the confirmation button as non-repeatable during that state

Scenario: Package payment confirmation recovers after terminal outcome

• WHEN the package payment flow ends because of success, failure, cancellation, validation failure, strong recharge prompt completion, or modal re-entry
• THEN the system SHALL clear the submitting state
• AND the user SHALL be able to start a new payment attempt

Requirement: Order list immediate payment SHALL prevent duplicate submission

The system SHALL prevent repeated taps on an order list item's immediate payment button from starting more than one payment submission flow for the current order at the same time.

Scenario: User taps order list immediate payment repeatedly during submission

• WHEN the user taps the immediate payment button multiple times before the current handleOrderPayment flow completes
• THEN the system SHALL execute only the first submission flow
• AND the system SHALL ignore subsequent taps until the current flow ends

Scenario: Order list immediate payment enters submitting state

• WHEN the first valid order list immediate payment tap is accepted
• THEN the system SHALL mark the current order payment flow as submitting immediately
• AND the system SHALL present the triggered immediate payment button as non-repeatable during that state

Scenario: Order list immediate payment recovers after terminal outcome

• WHEN the order list payment flow ends because of success, failure, cancellation, list refresh, or page re-entry
• THEN the system SHALL clear the submitting state
• AND the user SHALL be able to start a new payment attempt if the order remains payable

Requirement: Wallet recharge order immediate payment SHALL prevent duplicate submission

The system SHALL prevent repeated taps on a wallet recharge order item's immediate payment button from starting more than one recharge order payment flow for the current recharge order at the same time.

Scenario: User taps wallet recharge order immediate payment repeatedly during submission

• WHEN the user taps the immediate payment button multiple times before the current handleRechargePayment flow completes
• THEN the system SHALL execute only the first submission flow
• AND the system SHALL ignore subsequent taps until the current flow ends

Scenario: Wallet recharge order immediate payment enters submitting state

• WHEN the first valid wallet recharge order immediate payment tap is accepted
• THEN the system SHALL mark the current recharge order payment flow as submitting immediately
• AND the system SHALL present the triggered immediate payment button as non-repeatable during that state

Scenario: Wallet recharge order immediate payment recovers after terminal outcome

• WHEN the wallet recharge order payment flow ends because of success, failure, cancellation, list refresh, or page re-entry
• THEN the system SHALL clear the submitting state
• AND the user SHALL be able to start a new payment attempt if the recharge order remains payable

Requirement: Submit guards SHALL NOT change existing payment business rules

The system SHALL preserve the current recharge validation, recharge order payment, order list payment, order creation, strong recharge decision, wallet payment, WeChat payment, toast, modal, and balance refresh behavior while adding submit guards.

Scenario: Existing business validation remains unchanged

• WHEN the user submits with an invalid recharge amount or reaches an existing payment business rule branch
• THEN the system SHALL keep the current validation and messaging behavior
• AND the duplicate submission guard SHALL only affect repeated-trigger protection