dachui/order_site
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
1,098 Commits 3 Branches 0 Tags
6a5a8d70b0ec6500a76b0a704c0fca6927dd2453
Commit Graph
161 Commits
Author SHA1 Message Date
yml2213 319e082254 fix(douyin-mashida): 领取消息只发给有自动发货领取单元的单，人工单不再假发货 
根因：notifyBuyerClaimLink 对 `/h5` 形态的 claimLinkBase 走了一条捷径——只拼订单号
（`${base}/${orderNo}`）就发消息，跳过了「该订单项是否有自动发货领取单元」的校验。
领取 token 只由 affiliate_dash 执行器在建单时创建，未命中 AFFILIATE_DASH_SKU_MAPPING
回落 manual_dispatch 的人工单、以及自动准备失败的订单都没有 token，却照样收到
「您的订单已发货，请点击链接领取」（线上实测：非映射商品「套装-牛仔情诗」）。

- claim-link.ts：新增 buildDouyinMashidaBuyerClaimUrl（无自动领取单元一律返回空串 = 不发消息）
  与 isDouyinMashidaH5ClaimBase（/h5 形态判定收敛到一处）
- notify-service.ts：两种基址形态统一先 resolveOrderItemClaimLink 拿 taskId 作为「会自动发货」
  的证据，缺失则跳过并留痕「该订单项没有自动发货领取单元，跳过领取链接消息」
- claim-link.test.ts：补齐人工单不发消息、/h5 与 token 形态拼接、基址/订单号缺失等用例

验证：npm run check 全绿（prettier + SQL guard + eslint + tsc + 703 单测 + build）
 2026-10-13 13:48:58 +08:00
yml2213 b82f9c4063 fix(worker-platform): 补齐拼单份额超时自动处置机制与退回大厅流程 
- 根因排查：此前超时扫描仅针对整单 in_progress，而拼单母单为 open 且 deadline_at 为空，导致打手超时的拼单份额无法被定时扫描命中与释放；
- 定时扫描：在 settleOverdueWorkOrders 中引入 listOverdueWorkOrderShares，自动扫描超时未提交资料的拼单份额（joined）；
- 超时处置：新增 settleOverdueWorkOrderShare 事务处理，按母单 timeout_policy 释放或扣除押金，份额标记 cancelled，母单保持或恢复 open 状态重回抢单大厅，记录 timeout 事件并推送实时变更；
- 提交防呆：在打手提交拼单验收时检测个人份额是否已超时，超时则立即执行处置并拦截提交；
- 倒计时展示：在 mapWorkOrderForWorker 中根据 myShare.created_at + timeout_minutes 为拼单打手计算并展示个人履约截止时间；
- 质量验证：补齐拼单截止时间计算与处置链路测试，全量 676 个测试均通过，通过 npm run check 校验。
 2026-10-11 14:53:56 +08:00
yml2213 215f3351ba fix(claim): 优化H5领取与绑定界面商品图展示并集成发货存证凭据生成 
- 修复后端 affiliate_dash 领取详情接口漏传 imageUrl 字段的问题
- 优化前端 ClaimProductImage 占位逻辑，消除无图或失败时的空灰色方块
- 移植并集成 affiliate_dash 前端 Canvas 高清发货到账存证凭据（Retina 640x960）
- 在兑换成功页面提供结果图预览、一键复制到剪贴板与下载凭据图片功能
 2026-10-10 20:55:02 +08:00
yml2213 c54dbda344 feat(douyin-mashida): 全面统一为 /h5/<订单号> 直充路径，更新面板提示与直发链接生成 
- 抖音码速达买家直充链接与兜底配置基址统一改为 https://<域名>/h5（直充路径为 /h5/<订单号>）
- 前端配置面板示例与提示升级为真实 16 位平台订单号形态（如 /h5/2628301923197355）
- 一键填入域名同步适配 /h5 基址，并在后端发券与发货私信推送中直接生成 /h5/<订单号>
- 数据库本地配置同步更新为 http://localhost/h5

验证方式：前端类型检查与打包构建通过，全量 132 项前端单测与 674 项后端单测全部通过
 2026-10-10 20:10:09 +08:00
yml2213 d8ce40e346 feat(douyin-mashida): 彻底重构优化配置面板，支持一键填域名/订阅推送/网关自检并剔除冗余字段 
- 剔除历史旧卡券时代废弃的 afterVerifyLink（去使用链接）与 afterVerifyMessage（通知正文）
- 面板新增一键填入当前域名、向开放平台一键订阅推送、停用推送以及网关连通与签名自检功能
- 业务配置重构为「基础接入与商户凭据」、「买家 H5 直充与发货私信」、「高级网关设置」三层清晰结构
- 后端与前端服务新增 /douyin-mashida/subscribe 与 /douyin-mashida/test-gateway 统一接口

验证方式：前端类型检查与打包构建通过，全量 132 项前端单测与 674 项后端单测全部通过
 2026-10-10 20:05:46 +08:00
yml2213 4fce07a621 refactor(douyin-mashida)!: 纠偏——删掉自建的皮肤通道，改回复用 affiliate_dash 
上一轮我把皮肤交付做成了「另建一套执行器 + 独立领取接口 + 只提交账号就结束」，
跟买家实际要走的过程不一致（真正的完成信号是「扫码绑定后的 UID == 买家填的 UID」），
而且核销还触发了老通知逻辑，给买家**又发了一条 /redeem** —— 买家收到两条链接。
本次按用户要求改回**完全复用仓库现成的 affiliate_dash 通道**（= 旧的快手皮肤自动发货）。

**删掉**
- 执行器 `douyin_mashida_skin`（含 registry/types/planner/bootstrap/路由白名单注册）
- `services/claim/claim-skin-service.ts`、`routes/claim-skin.ts`、`/api/v1/claim-skin` 挂载
- 迁移 096 的 `claim_submission_json` 全链路（task-repo / rows / inputs / task-detail /
  admin-read-service 的 claimSubmission），并新增 **097 兜底迁移**把该列 DROP 掉
- 顺带清掉上一轮专为已删接口加的死代码（utils/http.ts 的 buildMessageSuccessPayload 等）

**改回复用**
- `resolveOrderItemClaimLink`：通用解析（只看订单项、不看执行器）→
  `buildConfiguredClaimUrl(claimLinkBase, token)`；多履约单元取 task id 最小并告警；
  **绝不回退** hash 形态的 `buildClaimUrl`
- `cert_link` 与付款后那条**唯一**消息共用同一个解析结果
- **核销后不再给抖音买家发第二条消息**（`shouldNotifyBuyerAfterVerify` 只放行非抖音 provider）
- 买家侧走既有流程：输 UID → 二维码 → 扫码绑定 → 比对 UID → delivered/REDEEMED；
  在 delivered 分支 best-effort 核销平台券（幂等、失败只 warn，不拖慢买家响应）
- 后台回显链接改按 **order.provider** 判断（抖音用 `claimLinkBase`）

**SQL 守卫**：允许「删除历史迁移」，但强制要求「同时新增兜底迁移」配对
（修改历史迁移仍禁止），并把改动来源换成 `git status --porcelain`（否则未跟踪的新迁移看不见）

`npm run check`：tests 671 / pass 668 / fail 0 / skipped 3（含新增的物品图回退用例）
 2026-10-09 16:13:39 +08:00
yml2213 56a8184576 feat(douyin-mashida): 皮肤自动发货（按内部 SKU 分流 + 领取链接 + 买家领取接口） 
抖音码速达的皮肤类商品改为「自动发货 + 领取链接」：买家不用输订单号，点链接直接领。

**分流（按内部 SKU）**
- 平台闸门放行 `provider='douyin_mashida' && platform='doudian'`，走**独立分支**
  （原有 91/快手路径一行未动，避免外溢）
- 判据：内部 SKU（`sku_order_list[].code`，即 order_items.sku_code）命中权威表
  `AFFILIATE_DASH_SKU_MAPPING` → 新执行器 `douyin_mashida_skin`；未命中 → `manual_dispatch`
- 皮肤判定与商品图同源（都用那张权威表），保证「能路由 ⇒ 有图」
- 履约路由新增 `internal_sku` 匹配维度（`rules[].internalSku`，NFKC+去空白+小写，exact/contains）；
  旧规则缺 `matchField` 时默认 `product_name`，**归一化/优先级/回退顺序完全不变**

**执行器与领取 token**
- 新增 `douyin-mashida-skin-executor`：建 claim token、置 `link_generated/pending_claim`，
  `resolveDeliveryLink` 返回本站路径式领取链接；注册进 registry、planner 分支、
  bootstrap 种子 profile（`抖音皮肤自动发货`）；进 `ROUTABLE_EXECUTOR_KEYS`
- token 粒度 = 一个履约单元一个（`claim_tokens.task_id` 唯一）；一单多项时
  cert_link/买家消息取 task id 最小的那个并告警

**cert_link 与发消息**
- 皮肤订单且该订单项已有 token 且配了 `claimLinkBase` → `cert_link = claimLinkBase/token`；
  其它情况一律用 `certLink`（老行为不变）
- 领取链接**只认** `claimLinkBase`，绝不回退 `buildClaimUrl`/`orders.claimBaseUrl`
  （那是 hash 形式的打手领取页，语义不同）
- 付款建单+发券成功后按 `messageTemplate`（`{link}/{sku}/{orderNo}/{productTitle}`）
  经 `order.message` 发给买家；best-effort，失败只记 warn

**买家领取接口**
- `GET/POST /api/v1/claim-skin/:token`（限流、公开）；详情含内部SKU/引流标题/商品图/
  数量/金额/支付时间/动态表单字段；token 失效给明确 errorCode（404/410/409），不打 500
- 提交账号：先核销平台券再落记录（避免「记账了但券没核销」的资损），已提交幂等

**隐私**
- 买家游戏账号落 `fulfillment_tasks.claim_submission_json`（迁移 096），
  **不进** `work_orders.material_json`（那是发给打手的素材）；详情接口不返回券码明文/手机号/地址/open_id
 2026-10-09 15:06:43 +08:00
yml2213 ecc8ffaee4 fix(douyin-mashida): 出网响应按大整数安全解析（product_id 被压精度） 
真实联调发现：抖店大量 id 是 19 位数字，超过 Number.MAX_SAFE_INTEGER，
入站推送我们用 express.text() 收原文保住了精度，但**出网响应是 JSON.parse 出来的**，
19 位数字在解析瞬间就被压成相邻 double：

  平台真值 product_id = 3847255376114352567
  我们存到的          = 3847255376114352600

后果：拿这个 product_id 去调 product.detail 报「商品不存在」（实测），
任何按商品ID做的映射/查询都会错。

修复：抖音出网响应改用共享的 parseJsonObject(..., { preserveLargeIntegers: true })。
utils/json.ts 里其实早有 wrapLargeIntegerLiterals（≥16 位/超 MAX_SAFE_INTEGER 才包裹，
只处理值位置的整数字面量，不误伤字符串内数字与短数字），但全仓没有调用方 —— 现在接上。

实测：同一笔订单 product_id 已精确为 …567，product.detail 返回 code=10000 并拿到商品图。
补了 json 解析的大整数单测（含「字符串里的数字、短数字不受影响」的反例）。
 2026-10-09 14:47:55 +08:00
yml2213 0b619b2915 feat(asset): 商品图资源 + 内部 SKU → 图片解析 
买家领取页要展示「待领取物品图片」，图片按 affiliate_dash 的英文 sku 命名
（如 lucky_coin_x2.webp = 内部 SKU「幸运币2个」），从 affiliate_dash 项目
复制 38 个 slug（40 个文件，其中 2 个 slug 同时有 png/webp）到前端 publicDir
`apps/frontend/public/images/products/`，由 Vite 原样对外（不进 bundle）。

新增 `services/platforms/affiliate-dash/product-image.ts`：
内部 SKU →（复用权威映射表 AFFILIATE_DASH_SKU_MAPPING）→ 英文 sku → 图片 URL。
映射不到返回空串，由前端展示占位图（不猜、不拼不存在的文件）；
以后图片挪 CDN 只改这一处。

测试含「映射表每个 sku 都必须有对应图片文件」的守卫，防止新增商品漏图。
 2026-10-09 14:47:50 +08:00
yml2213 de2fb3e008 fix(douyin-mashida): 平台会改写券码 —— 核销改用平台侧券码 + 失败自愈 
真实联调踩到的坑（已用真单复现并定位）：
`coupons.syncV2` 返回 `10000 成功` **并不代表平台沿用了我们提交的 cert_no**。
实测 3 笔订单里有 2 笔，平台把我们的 DYC 券码换成了它自己生成的券码。
我们却一直拿**自己的**券码去 `coupons.verifyV3`，平台回
`10017 卡券核销失败[isv.business-failed:010021|核销码与订单不匹配]`；
更坑的是这个错误平台要 **~10.5 秒**才返回，正好越过当时的 10 秒超时，
前端只看到 `douyin_mashida_gateway_timeout`，完全看不出真实原因。

修复：
- 新增 `coupons.list` 出网封装；同步成功后按 order_id 回查平台侧 `cert_no`/`cert_id`
  并落库（迁移 095 新增 platform_cert_no / platform_cert_id / platform_status / platform_synced_at）
- 核销时用 `resolveRedeemVerifyCertNo()`：**平台侧券码优先**，取不到才退回我方券码
- 核销失败后自愈 `tryRecoverVerify()`：
  ① 回查平台，若平台侧已核销 → 按对账结果标记本地已核销（修复"平台已核销、我们报失败"的漂移）
  ② 若是券码被平台改过 → 用平台券码**重试一次**
- 回查不到该订单的券 → 标记 sync 失败并告警（暴露"syncV2 成功但平台无券"的幽灵券）
- 默认出网超时 10s → 20s（平台业务错误要 ~10.5s 才返回，10s 会把业务错误伪装成超时）

实测验证：对一笔「平台侧已核销、本地仍是 synced」的订单调确认兑换，
10.7s 后返回 `status=verified`，platform_cert_no 成功回填为平台券码、
platform_status=3，并打出「对账发现平台侧已核销，按平台状态标记本地已核销」告警。
 2026-10-09 14:08:55 +08:00
yml2213 064267ad86 fix(douyin-mashida): pay_time 兼容平台实际返回的字符串格式 
真实联调发现：`order.orderDetail` 返回的 `pay_time` 是格式化字符串
`"2026-10-09 12:28:02"`（北京时间），而文档写的是秒级 Integer，
消息推送里的 `pay_time` 又确实是 Integer —— 两种形态并存。

原实现只走 `parseEpochSecondsIso`，对字符串 `Number("2026-10-09 12:28:02")` = NaN，
会把真实支付时间丢掉、退化成"收到时间"。

改为 `parseDouyinMashidaTimeIso`：纯数字按秒级时间戳，`YYYY-MM-DD HH:mm:ss`（含 T）
按 +08:00 解析；平台用 `1970-01-01 08:00:00`（epoch 0）表示"无"，返回空串。
用真实 orderDetail 响应反例补了单测（含 19 位订单号 + 子单号等于父单号）。
 2026-10-09 12:43:24 +08:00
yml2213 72606796b3 feat(douyin-mashida): 抖音码速达最小接入后端（消息建单/券码同步/兑换核销/退款作废） 
- 签名：出网 md5(secret+Σ(名+值)+secret) 与推送 md5(secret+data+pub_time+topic+secret)
  两套独立实现，含文档 golden 向量单测（与 91 大写 / affiliate_dash HMAC 都不通用）
- 进单：trade_TradePaid 推送 → 验签 → webhook_events 幂等 → order.orderDetail
  → upsertOrderFromSource（provider=douyin_mashida / platform=doudian）
- 精度：19 位订单号超出 JS 安全整数，JSON.parse 会把 p_id 抹成 ...000；
  故解析后从原始 JSON 文本用正则抓回精确数字（单测同时证明"不修会错"）
- 券码：迁移 094 redeem_certificates（(provider,order_id) 唯一做发券幂等）
  + DYC 券码生成 + coupons.syncV2 同步（子单号优先、父单兜底）
- 兑换：POST /api/v1/redeem/lookup|confirm，按 orderNo+IP 限流；
  核销成功后 order.message 通知买家（best-effort，失败只记错误日志）
- 退款/取消：作废未核销券；券已核销时打 WARN 资损告警（已消费不可回滚）
- 后台：GET/POST /api/v1/admin/platform-config/douyin-mashida，
  secret 出参置空 + 掩码，掩码回写不覆盖原值
- 消息路由挂在全局 body parser 之前（app.ts），验签必须用 body 原始字符串
 2026-10-09 12:00:50 +08:00
yml2213 af6dc27017 feat(sku): 新增 Rock 平台「黑色ROCK长袖T恤」与「蓝色运动服上衣」SKU 映射 
1. 在 AFFILIATE_DASH_SKU_MAPPING 中新增黑色ROCK长袖T恤 (rock_black_tshirt) 与蓝色运动服上衣 (rock_blue_sportswear) 权威映射；
2. 兼容常见别名「黑色ROCK长袖」与「蓝色运动服」，确保电商出单时自动准确路由至 affiliate-dash 进行 0666.pro 全自动发货履约。
 2026-10-05 19:25:24 +08:00
yml2213 0173efb277 feat(pdd): 店铺连续同步失败 3 次后熔断，停止自动重试 
背景：生产上「木塔网游专营店」Cookie 已过期，每约 24 秒重试一次、每轮刷一条 ERROR 日志，
持续数天。Cookie 失效不会自愈，继续重试只刷日志、白白占用同步周期。

行为：
  - 失败 1~2 次：累计计数，继续重试；
  - 第 3 次：熔断，打一条显式 ERROR（含"更新 Cookie 会自动恢复"提示）；
  - 熔断后：自动同步直接跳过，不再刷错误日志；
  - 恢复：更新 Cookie（后台编辑或浏览器插件）自动解除；手动同步成功一次亦可。
  熔断状态持久化在店铺配置里，容器重启后依然生效。

改动：
  - pdd-source-config-service：阈值常量 + consecutiveFailures/syncSuspendedAt/
    syncSuspendedReason 持久化字段 + 纯函数 resolvePddStoreFailureState /
    applyPddStoreBreakerState / isPddStoreSyncSuspended / shouldResetPddSyncBreaker。
  - pdd-sync-service：syncAllPddStores 跳过熔断店铺并上报 suspendedCount；
    syncStoreOrders 失败记录、成功清零（健康店铺不产生额外配置写）。
  - pdd-order-sync-job：上报熔断数，且存在熔断店铺时强制留在 INFO 级
    （否则"全部店铺已停同步"会因新单为 0 被降级成 debug 而不可见）。
  - 前端加「已熔断 · 停止重试」标签与类型字段。

顺带修掉一个隐患：saveAdminPddStore 收的是 Partial 载荷，normalizePddStoreItem
会为缺失字段产出 undefined，导致一次「只改店铺名」的保存就把熔断洗掉。
由 applyPddStoreBreakerState 回填既有状态解决。

验证：9 项熔断单测（含局部保存不洗状态、Cookie 变更解除熔断）。
 2026-10-03 14:27:38 +08:00
yml2213andCursor 1239393fc2 perf: 筛选统计去掉 JSON 兜底，并补上 orders 覆盖索引 
去掉 work_orders 堆访问后，JOIN 会把 orders 整表扫进 Hash Right Join。
领取页在快照新鲜时不再打上游；快手出网统一 10 秒超时。倒计时改为自适应间隔。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-10-01 15:05:38 +08:00
yml2213 0b4ee964ed feat(pdd): 引入拼多多原始订单暂存仓 pdd_raw_orders 与两段式解耦流水线 
1. 数据库新增 081_pdd_raw_orders.sql 迁移，创建 pdd_raw_orders 原始暂存表及索引；
2. 新增 pdd-raw-order-repo 仓储，支持原汁原味批量暂存、pending 单据消费、状态回填与重置；
3. 重构 pdd-sync-service 为采集暂存（Staging）与业务进单（Ingestion）两段式解耦流水线，实现断点续传；
4. 管理后台路由接入 raw-orders 原始流水查询及 replay 一键历史单重放 API。
 2026-09-19 11:58:28 +08:00
yml2213 5e59a5fdb1 fix(order-service): 修复包含 Emoji 和孤立代理字符的订单在 PostgreSQL jsonb 下报错导致死循环重试进单的问题 
1. 在 utils/json.ts 新增 sanitizeWellFormedUnicode、deepSanitizeUnicode 和 safeJsonStringify，自动清理空字节 (\0) 并将畸变孤立 UTF-16 代理字符 (Lone Surrogates) 安全转换为规范字符，杜绝 PostgreSQL jsonb 解析错误；
2. 拼多多订单映射器与通用进单服务 (order-service) 全面接入 Unicode 深度清洗与安全序列化，确保买家昵称/留言中的各类特殊 Emoji 和生僻字符平滑落库；
3. 数据库仓储层 (order-repo / order-item-repo) 针对 raw_payload_json、spec_json、item_snapshot_json 等 jsonb 字段增加兜底安全序列化保护；
4. 补充 utils/json.test.ts 与 pdd-order-mapper.test.ts 单元测试，覆盖畸变字符与空字节场景。
 2026-09-19 11:40:02 +08:00
yml2213andCursor acfe7fd07e style: 修复订单与调度相关 Prettier 格式 
Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-15 13:48:43 +08:00
yml2213andCursor 40278a68fc chore(logging): 降噪 PDD 同步与发单消费者常态日志 
将无新单/全跳过的处理完成日志降到 debug，并压缩 decisions 详情，避免 app 日志被按日切碎。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-15 13:48:30 +08:00
yml2213andCursor b7d246e5b9 fix(admin): 任务列表商品名与执行器标签改为中文展示 
建单时不再把英文 sku 写入商品名，列表按映射反查中文名，并将 Affiliate Dash 等标签本地化。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-15 13:03:47 +08:00
yml2213andCursor 8eef95fe97 style: 修复 affiliate-dash http-client Prettier 格式 
Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-15 12:05:18 +08:00
yml2213andCursor 8e996e01fb fix(pdd): 停止旧单刷匹配日志，并修复订单列表商品显示为 0 
同步时已有工单/匹配结果未变不再写日志；列表按 Number(order_id) 挂 items，并补齐 PDD goods_name 回退与嵌套商品解析。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-15 12:05:02 +08:00
yml2213andCursor 2e197f93e0 fix(claim): 透出 affiliate_dash 上游错误，便于排查提交 UID 失败 
上游 4xx 不再一律打成 502 兜底文案；affiliate_dash 依赖错误优先展示真实 message。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-15 11:51:32 +08:00
yml2213andCursor e20505bc8e style: 修复 pre-push Prettier 格式检查失败 
Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-15 10:47:38 +08:00
yml2213andCursor 4a3b4ec14d refactor(fulfillment): 固化 91 中文名→英文 SKU 权威映射表 
91 继续用中文编码；解析优先查内置常量表，配置仅作临时覆盖，Admin 改为展示权威表。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-14 20:33:42 +08:00
yml2213andCursor b3aad0044c refactor(fulfillment): 移除飞飞/乐玩通道，仅保留 affiliate_dash 
新单只路由 affiliate_dash（未命中走 manual_dispatch）；历史飞飞/乐玩任务保留只读 stub，避免订单重同步失败。同步清理 cloudtentacles 调度、Admin 写路径与相关 env。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-14 17:29:47 +08:00
yml2213 0cbcb89dd8 feat(pdd): add realistic Bézier mouse trajectory simulation to generate 700+ char anti-content tokens 2026-09-14 14:03:07 +08:00
yml2213 f35e47e419 fix(pdd): integrate official sandboxed anti-content engine to resolve 40002 WAF error 2026-09-14 13:44:55 +08:00
yml2213 4f97275c80 fix(pdd-extension): 拼多多官方接口频控(40002)容错与轻量探测，避免有效 Cookie 被拒 2026-09-14 13:09:16 +08:00
yml2213 a47661e67e fix(pdd-extension): 增强 MMS Cookie 多维嗅探与 PASS_ID 校验，新增插件运行日志与升级 v1.1.0 2026-09-14 12:50:54 +08:00
yml2213 9fb27b0ad2 feat(pdd): 拼多多订单支持 out_sku_sn 匹配与浏览器插件加密保活 
- 拼多多进单 Cookie 失效即时拦截与告警修复（支持 43001 会话过期等错误识别）
- 拼多多订单映射优先使用 out_sku_sn（外部商家编码）作为商品规格与工单匹配核心字段
- 新增 Chrome/Edge 浏览器扩展 (Manifest V3)，支持端到端 RSA-OAEP + AES-256-GCM 信封加密自动保活
- 后台店铺管理新增插件配对面板、专属密钥管理与一键导入配置 JSON
 2026-09-14 12:24:48 +08:00
yml2213 fea82bff36 style(backend): 格式化代码并修复floating-promises以通过pre-push检查 2026-09-12 17:46:47 +08:00
yml2213 8cc3aa2a35 fix(pdd): 拼多多商品名称仅展示规格spec，过滤冗长原标题 2026-09-12 16:53:30 +08:00
yml2213 ede9a87b97 feat(pdd): 支持根据数据库已有订单自适应翻页拉取，防高峰漏单 
1. 新增数据库批量排查已有订单接口 findExistingPlatformOrderIds，利用 B-Tree 索引毫秒级判定当前页订单是否存在；
2. 优化 syncStoreOrders 支持自适应翻页拉取：当第 1 页全部为新订单时，自适应向后递增翻页拉取（支持 maxPages 默认 5 页，平滑限速 300ms）；
3. 翻页终止自适应判定：当拉取到包含数据库已有旧订单的页面时立即 break 停止翻页，兼顾高性能与不漏单；
4. 扩展全局配置支持 maxPages（自适应最大翻页页数），支持后台管理员在 UI 设置与立即拉单参数联动；
5. 新增单元测试 pdd-sync-service.test.ts，验证全部新订单自适应翻页与命中已有订单提前终止行为。
 2026-09-12 16:25:37 +08:00
yml2213 c8f7e48746 feat(pdd-cookie): 持久化保存Cookie校验状态时间并在失效时发送内部告警通知 2026-09-12 15:26:40 +08:00
yml2213 ffa3374483 feat(pdd-sync): 默认拉取已发货订单并支持配置单次拉单上限与抓取状态 2026-09-12 15:16:39 +08:00
yml2213 44e752d205 feat(pdd-ui): 新增管理后台拼多多店铺CRUD与Cookie有效性实时检测功能 
1. 订单快照优化 (pdd-order-mapper.ts):
   - 在 item_snapshot_json 中完整保留拼多多原始报文快照全量字段，确保无信息截断。

2. 后端 Cookie 有效性校验接口 (pdd-client.ts, platform-config/pdd.ts):
   - 新增 PddClient.testCookie 与 POST /api/v1/admin/platform-config/pdd/test-cookie 接口。
   - 支持通过轻量接口请求即时测试 Cookie 合法性，精准识别有效状态（返回在线订单数）与失效/频控状态。

3. 前端管理面板开发 (PddPlatformPanel.tsx, AdminPlatformShopsPage.tsx):
   - 在平台配置页面新增【拼多多 (PDD)】专属 Tab 面板。
   - 提供拼多多全局同步开关与轮询间隔配置。
   - 支持店铺完整 CRUD：添加店铺、编辑店铺、删除店铺、启用/停用切换。
   - 支持弹窗内即时【测试此 Cookie 有效性】（无需先保存即可验证）及列表行内一键测活与单店铺立即同步。
 2026-09-12 14:27:40 +08:00
yml2213 424c320183 feat(pdd): 原生内嵌拼多多多店铺订单同步子服务与anti-content纯算引擎 
1. 纯算引擎 (pdd-anti-content.ts):
   - 100% 纯 TypeScript 原生还原 0as anti-content 算法，零 npm 依赖（仅基于 Node.js 原生 zlib 与 crypto）。
   - 包含 22 个环境特征 Tag TLV 组包、zlib 标准压缩、4 字节尾部扰动盐与 64 字符动态位移 Base64 编码，单次耗时 < 0.1ms。

2. MMS 接口客户端与数据映射 (pdd-client.ts, pdd-order-mapper.ts):
   - 基于原生 fetch 实现高可用 MMS 请求，支持拼多多网关毫秒级服务器时间校准 (/api/server/_stm)。
   - 实现拼多多订单状态与字段规范映射为平台 SourceOrderEvent，精准保留买家留言与充值账号信息。

3. 多店铺配置与防风控错峰调度 (pdd-source-config-service.ts, pdd-sync-service.ts):
   - 支持多店铺账号配置持久化（PostgreSQL app_config_entries 与本地 JSON 双模兜底）。
   - 实现店铺间轻量错峰拉取机制，避免并发峰值触发平台 40002 频控。

4. 内存级自动进单与派单流转:
   - 拉取新订单后在 Node.js 内存中直接调用 upsertOrderFromSource()，自动完成 orders/order_items 入库、商品规则匹配与打手大厅工单 (work_orders) 实时广播。

5. 调度器与管理端 API (scheduler-service.ts, platform-config/pdd.ts):
   - 注册 pdd_order_sync 定时任务（默认 20s 轮询），提供管理端店铺配置查看、保存、删除及手动立即同步接口。
   - 所有新增代码均遵循中英双语注释规范，并通过类型检查与单元测试。
 2026-09-12 14:12:11 +08:00
yml2213 076b113ae5 feat(kuaishou-industry): 实现电子凭证自动核销推进器与查码流程优化 
- 新增 voucher-auto-consume-service，对非发单平台大厅待发布任务实现生成即核销与发码成功闭环核销
- 严格保留发单平台待发布工单（pending_material/unassigned）在大厅发布时核销逻辑
- manual-executor 在任务生成进入 MANUAL_REVIEW 时直接触发核销
- send-code-service 在发码出站回调成功后自动调度非大厅任务的凭证核销
- 优化 query-code-service 查码接口，避免发码初期误报 4012002 订单不存在
- 标记废弃 kuaishou_feifei 渠道模块
- 补齐 voucher-auto-consume-service 单元测试用例
 2026-09-10 10:01:40 +08:00
yml2213 de63daf1ac 优化订单履约分流与后台筛选 2026-09-02 11:59:38 +08:00
yml2213 2aa8769661 改造实时事件缓存同步 2026-08-17 17:32:02 +08:00
yml2213 18dad9b0fe 增加订单实时状态同步 2026-08-17 14:51:51 +08:00
yml2213 81ae04dae0 接入 ESLint 并清理未使用代码 
- 前后端接入 ESLint 10 扁平配置（typescript-eslint 类型感知检查 + react-hooks/react-refresh），新增 lint / lint:check / lint:fix 脚本并纳入 check 链路
- 清理全部 no-unused-vars 与 no-useless-assignment 警告，修复 floating promises、正则转义等问题
- 删除确认无引用的死代码（markKuaishouCloudBindUrlRefreshFailed、未使用 helper 等）
 2026-08-16 18:04:55 +08:00
yml2213 5c7c3e14e3 统一前后端代码格式化配置 2026-08-16 17:27:12 +08:00
yml2213 a7de443cb9 优化 不在频繁报错 试 91 订单失败 2026-08-10 16:51:45 +08:00
yml2213 bcde47ef97 彻底修复 lewan 自动发货问题-8-8-2 2026-08-08 23:43:29 +08:00
yml2213 6e41d7e0db 彻底修复 lewan 自动发货问题-8-8 2026-08-08 23:08:05 +08:00
yml2213 e8eab6e689 fix(kuaishou-industry): 修复电子凭证发货回调并发导致 807000 获取并发锁失败 
同一 oid 的发货回调可能被多个来源并发调度（内存重试链 timer、worker_scan
兜底扫描、快手重复推送 send-code 后的再次调度），快手侧对同一 oid 有并发锁，
并发请求会返回 807000「获取并发锁失败」。

- runKuaishouIndustrySendCallbackForOid 增加进程内 in-flight 互斥，
  正在执行时其它调度直接跳过，由当前执行链路决定成功或按 backoff 重试
  （try/finally 保证所有 return 路径释放）
- listKuaishouIndustryVouchersForSendCallbackRetry 增加 maxAttempts 参数
  及 SQL 条件 COALESCE(send_callback_attempt_count,0) < ，缩小扫描集
 2026-08-05 20:05:43 +08:00
yml2213 769d41655a 优化履约匹配:指定匹配(91中文名→sku映射)最高优先 + 映射键归一化 
- 91 商品编码全部为中文名(幸运币90个等),运营按中文名→affiliate_dash sku 配置显式映射
- resolveFulfillmentRoute 新增 preferredExecutorKey:映射命中强制优先(规则之前),停用/不可用回退原逻辑
- matchAffiliateDashSku 归一化:NFKC 全角→半角、去空白、小写,先精确再遍历
- preferredMatchEnabled 配置(默认 true,可一键回退,不耽误现有 cloud/feifei 生产)
- 测试 +9(221 全绿);行为验证:映射命中/全角/空格命中,未映射回退
 2026-08-05 16:44:37 +08:00
yml2213 7fc3d60588 新增 affiliate_dash 回调路由与幂等去重(阶段 5) 
- POST /api/v1/open/affiliate-dash:验签 → 查任务(404 重试) → webhook_events 幂等闸门 → 状态同步
- migration 013:webhook_events(provider+event_id 唯一)
- task-repo findAffiliateDashTaskByOrder(仿 feifei 同构 SQL)
- notify-service:去重闸门在找到任务之后,任务未匹配不被 eventId 永久拦截
- typecheck + 212 测试通过;前置错误分支脚本验证通过
 2026-08-05 16:07:33 +08:00