统一订单单状态模型

docs/API对接关系.md

@@ -28,12 +28,12 @@
   ↓ POST /api/open/v1/orders/ship-notify
 只回传 success 或 failed
   ↓
-本平台更新履约状态
+本平台更新订单状态
   ↓
 商户回调 / 商户查询订单
 ```
 
-当前流程不再维护独立的 `fulfillment_jobs` 任务表；履约事实以订单表里的 `fulfillment_status`、上游单号、发货时间和失败原因等字段为准。
+当前流程不再维护独立的 `fulfillment_jobs` 任务表；订单事实以订单表里的 `order_status`、上游单号、发货时间和失败原因等字段为准。
 
 ## 3. 鉴权不要混用
 
@@ -51,17 +51,16 @@
 
 ## 4. 状态语言
 
-内部订单使用 `payment_status` + `fulfillment_status` 两组状态；源头侧为了兼容对接，返回的是更贴近发货系统的旧状态名。
+平台内部、商户侧开放 API、源头侧查询和商户回调统一使用 `order_status`。
 
-| 内部 payment_status | 内部 fulfillment_status | 源头侧 `status` | 含义 | 是否可发货 |
-|---------------------|-------------------------|-----------------|------|------------|
-| `paid` | `pending` | `paid` | 已付款，等待发货 | 是 |
-| `paid` | `processing` | `delivering` | 履约中 | 否 |
-| `paid` | `succeeded` | `delivered` | 已交付 | 否 |
-| `paid` | `failed` | `ship_failed` | 发货失败，可重试 | 是 |
-| `refunded` | `cancelled` | `cancelled` | 已取消 / 已退款 | 否 |
-
-注意：源头侧返回的 `status=paid` 不是单独的支付状态，而是“这个订单已支付且处于待发货履约状态”的兼容表达。
+| order_status | 含义 | 是否可发货 |
+|--------------|------|------------|
+| `pending` | 待支付（当前无真实支付流程，仅预留） | 否 |
+| `paid` | 已支付/已扣款，待发货 | 是 |
+| `delivering` | 发货中 | 否 |
+| `delivered` | 已交付 | 否 |
+| `ship_failed` | 发货失败，可重试 | 是 |
+| `cancelled` | 已取消 / 已退款 | 否 |
 
 ## 5. ship_notify 当前契约
 

docs/发货通知约定.md

@@ -11,7 +11,7 @@
 - `success` 表示发货成功
 - `failed` 表示发货失败
 - `failed` 时，`fail_reason` 必填，且要写详细失败原因
-- `processing` 是旧口径里曾出现过的中间状态，当前 `ship_notify` 不再接受
+- `ship_notify` 不接受中间态，提交发货时由平台内部将订单置为 `delivering`
 
 ## 2. 推荐推送格式
 

docs/开放接口-皮肤源头对接.md

@@ -216,7 +216,7 @@ GET /api/open/v1/orders/{order_no}
 
 ## 4. 接口二：发货结果推送
 
-> 当前接口只接受 `success` / `failed` 两种最终结果。`processing` 是旧口径里曾出现过的中间状态，当前 `ship_notify` 不再接受；当 `ship_status=failed` 时，`fail_reason` 必须填写详细失败原因。
+> 当前接口只接受 `success` / `failed` 两种最终结果；当 `ship_status=failed` 时，`fail_reason` 必须填写详细失败原因。
 
 ### 4.1 请求