order_site

Files

T

yml2213 1ffcbec771 docs(抖音-码速达): 结合 order_site 的接入深度分析

新增 docs/抖音-码速达/04-结合本项目的深度分析.md（358 行），把新平台协议
数据与本仓库现有架构对齐，回答「能不能接、怎么接、代价与风险」：

- 现状摸底（全部带代码位置）：进单主链路 upsertOrderFromSource / 履约执行器
  契约与注册表 / 履约路由白名单 / 商品解析分支 / webhook 幂等闸门 / 配置体系
  / 审计与 RBAC / 调度 / 可观测性；并指出目前只有 91 卡券一条「推送式进单 →
  自动履约」完整通路，仓库内无任何码速达实现代码。
- 能力映射：14 条消息 → 本系统动作（7 条可直接复用订单状态机，5 条售后/仲裁
  本系统无对应模型）；16 个接口 → 本系统能力（topup.result 回执、coupons.*
  券码链路、afterSale.* 售后为全新）；字段级映射与状态映射建议表。
- 关键差异：trade_TradePaid 不含商品与买家账号，必须再调 order.orderDetail
  补全；码速达推送没有 event_id，给出 4 种幂等键方案（推荐 topic+pub_time+
  p_id:s_id，body 哈希兜底）；协议无 nonce，防重放只能靠时间窗 + 幂等表。
- 差距清单 11 项（G1~G11）：签名/出网、消息入口、商品解析分支、状态映射、
  topup.result 回执、卡券、售后、配置面板、对账补偿、成本与可观测、env 白名单
  硬约束；每项给出影响、落点文件与规模估算。
- 7 个待拍板设计决策 + 分 5 期实施计划（含每期落点文件与验收标准）+ 测试方案
  + 风险清单 + 10 条合规红线（密钥只读不回显、买家隐私不进工单素材等）
  + 待确认问题清单（给平台方 6 条 / 给业务方 3 条）。

结论：主干可复用约 70%，协议层/状态映射/回执/卡券需新写；打通进单+回执约
6~10 人日，卡券+售后+面板再加 8~12 人日。已同步更新目录索引 README.md。

2026-10-08 14:14:09 +08:00

affiliate_dash_发货平台

docs: 清理过时文档（以代码为准）

2026-09-17 16:57:27 +08:00

91卡券

docs: 清理过时文档（以代码为准）

2026-09-17 16:57:27 +08:00

发货平台-2

优化客服权限

2026-07-10 12:00:23 +08:00

履约配置

fix(claim): 修复后台手动关闭任务后领取链接未失效的缺陷