one-pipe-system/openspec/changes/update-exchange-refund-interception-feedback/specs/exchange-management/spec.md

ADDED Requirements

Requirement: Exchange Creation Refund Interception Feedback

The exchange creation page SHALL display the backend business reason when POST /api/admin/exchanges rejects the selected old asset because of an active refund application. The page MUST use the response code and msg contract without changing the successful exchange response structure.

Scenario: Display active refund interception reason

• GIVEN 用户已填写创建换货单表单并选择存在活跃退款申请的旧资产
• WHEN POST /api/admin/exchanges 返回失败 code 和 msg
• THEN 页面 MUST display the backend business reason in the create exchange form context
• AND 当后端 msg 为“该资产存在退款申请”时，页面 MUST display that message directly
• AND 系统 MUST NOT create a new exchange order

Scenario: Display other exchange creation business reason

• GIVEN 用户已填写创建换货单表单
• WHEN 创建接口返回非退款相关的业务失败 code 和 msg
• THEN 页面 MUST display the backend msg in the create exchange form context
• AND 页面 MUST NOT replace the backend business reason with a generic frontend failure message

Requirement: Exchange Creation Retry After Interception

The exchange creation page SHALL preserve the current form values after a backend rejection and allow the user to change assets and submit again after the request completes.

Scenario: Preserve form after refund interception

• GIVEN 创建换货单请求被后端退款规则拒绝
• WHEN 页面展示后端业务原因
• THEN 页面 MUST retain the selected old asset, new asset when applicable, flow type, reason, and other form values
• AND 提交按钮 MUST leave its loading state after the request completes

Scenario: Retry with another asset

• GIVEN 用户已收到退款拦截错误
• WHEN 用户更换旧资产并再次提交创建换货单
• THEN 系统 MUST send a new POST /api/admin/exchanges request using the updated form values

Requirement: Backend-Controlled Exchange Refund Eligibility

The exchange creation page MUST rely exclusively on the exchange creation response to determine refund-related eligibility. The frontend MUST NOT add a refund status lookup, a refund pre-check area, or infer eligibility from refund approval, rejection, withdrawal, or completion states.

Scenario: Do not pre-check refund eligibility

• WHEN 用户打开或填写创建换货单表单
• THEN 页面 MUST NOT issue a refund status query solely to determine exchange eligibility
• AND 页面 MUST NOT render a refund status pre-check area

Scenario: Permit assets according to backend decision

• GIVEN 用户选择曾有退款申请但后端允许换货的资产
• WHEN 创建接口成功返回
• THEN 页面 MUST treat the exchange creation as successful
• AND 页面 MUST NOT block the operation based on a frontend interpretation of refund history