补全一些基础信息

docs/91卡券/6.开发设计.md

@@ -10,18 +10,21 @@
 目标能力：
 
 1. `91卡券` 调用我方异步下单接口；
-2. 我方将订单接入当前项目，走现有快手 Cloud 履约链路；
-3. 我方生成领取链接 `https://221329.cc.cd/#/claim/{token}`；
-4. `91卡券` 调用查询订单接口；
-5. 我方在 `cards` 中返回领取链接，由 `91卡券` 自动发货给买家。
+2. 我方将订单作为独立接入平台订单写入当前项目；
+3. 已配置商品自动走现有快手 Cloud 履约链路；
+4. 未配置商品进入后台待补全队列，可手动补齐履约信息后重试；
+5. 我方生成领取链接 `https://221329.cc.cd/#/claim/{token}`；
+6. `91卡券` 调用查询订单接口；
+7. 我方在 `cards` 中返回领取链接，由 `91卡券` 自动发货给买家。
 
 ## 2. 设计原则
 
 - `91卡券` 作为**新的订单来源**，不复用 `agiso`、`khhao`。
-- `91卡券` 不是新的履约执行器，而是外部售卖和自动发货通道。
+- `91卡券` 不是新的履约执行器，而是外部售卖、订单输入和自动发货通道。
 - 当前项目真正的交付物仍然是 `claimUrl`。
 - 查询接口返回 `20` 的判断标准是“领取链接已生成并可发”，不是“快手最终兑换完成”。
 - `buyNum > 1` 时，必须拆成多个 task，并返回多个 card。
+- 未命中履约配置时不丢单，先返回 `10` 并沉淀到后台待补全队列。
 
 ## 3. 来源建模
 
@@ -162,9 +165,9 @@ platforms: {
 下单接口成功判定标准：
 
 - 请求合法；
-- 商品已匹配；
 - 订单已成功写入；
-- 至少创建出 1 个 task。
+- 商品已匹配时至少创建出 1 个 task；
+- 商品未匹配时进入待补全队列。
 
 满足以上条件即返回：
 
@@ -197,6 +200,7 @@ platforms: {
   - task 进入失败/人工处理态且无法生成领取链接。
 - `10`：
   - 订单存在；
+  - 商品履约配置尚未补齐；
   - 任务已创建；
   - 但并非所有 task 都已准备好 `claimUrl`。
 - `20`：
@@ -299,7 +303,7 @@ Node 侧实现等价为：
    - 空值参数参与签名。
 2. 下单：
    - 业务请求映射为内部 source event；
-   - 商品未配置时返回 `30`。
+   - 商品未配置时返回 `10`，并进入后台待补全队列。
 3. 查询：
    - 全部 task 都有链接时返回 `20`；
    - 部分 task 缺链接时返回 `10`；
@@ -313,4 +317,4 @@ Node 侧实现等价为：
 - 不实现 `callbackUrl` 主动回调；
 - 不在 `91` 查询成功后回写快手侧最终兑换结果；
 - 不实现除 `aes-256-ecb-base64` 之外的卡密加密算法；
-- 不新增专门的后台管理页面。
+- 不新增独立顶级菜单，后台入口复用“平台配置 -> 91卡券接入”。