dachui/order_site
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
1,082 Commits 3 Branches 0 Tags
0f7d9d4fad519aa543adf5eb3c9166d829692b2d
Commit Graph
1009 Commits
Author SHA1 Message Date
yml2213 0f7d9d4fad feat(cost-center): 记住载体/Tab 选择，补配置引导并优化表格列宽 
- 新增 usePersistedState：载体工作区与 Tab 存 localStorage（admin-cost-center:carrier / :tab），
  刷新后保持；存储值非法或 Tab 不适用于该载体时自动回退
- 成本项目增加配置说明与常用成本项模板（采购成本/打手报酬/人工成本/平台费/通道费/售后损失），
  成本项行新增「加版本」并按成本类型预选范围；成本项/版本弹窗补字段说明
- 商品与成本中心 8 张表统一 tableLayout=fixed，名称类列定宽 + 省略 + tooltip，
  表格最小宽度按列宽之和设置，避免名称列独占剩余宽度
 2026-10-22 14:36:56 +08:00
yml2213 b520a078b0 feat(cost-center): 商品与成本按履约载体分区，补充分页与删除能力 
- 新增迁移 107_product_catalog_carrier：product_catalog 增加 carrier_type，
  自动发货只认 fulfillment_tasks.executor_key='affiliate_dash' 的履约证据
  （28 个上游 SKU），接单模板商品统一归为 work_order（662 个）
- 页面按「全部 / 自动发货 / 接单平台 / 人工客服 / 共用成本」分区；
  自动发货只展示自动发货 SKU 列表与采购成本，不展示商品目录/渠道映射
- 新增「同步自动发货商品」接口与按钮，按 aff:<skuCode> 幂等补建
- 列表统一接入公共分页 buildAdminTablePagination，支持 10/20/50/100 每页条数
- 标准商品、自动发货 SKU、渠道映射、成本项目、成本版本支持删除，
  带引用保护（映射/版本/快照/订单/接单规则）与生效版本先停用约束
 2026-10-22 14:05:34 +08:00
yml2213 8f3babdabe chore(db): 成本中心迁移重编号到 main 之后（103–106），check:sql 允许纯重编号 2026-10-22 12:42:59 +08:00
yml2213 3e73289e31 merge: 合并 main 到 feat/cost-center-wip（同步抖音券、设备认证与图标等最新改动） 2026-10-22 12:40:18 +08:00
yml2213 33b220ae10 fix(dcauth): order_site 白名单补充生产域名 ks.khhao.com 2026-10-22 10:04:05 +08:00
yml2213 d94a648c80 style(admin): 格式化后台用户管理页 2026-10-22 09:21:06 +08:00
yml2213 7a03abf8a1 feat(ui): 新增运营后台站点图标并统一登录页品牌标记 
- 新增橙色渐变仪表盘图标（SVG / ICO / apple-touch-icon / 192 / 512）
- 登录页侧栏与移动端品牌标记改用同一 BrandMark
- index.html 补齐图标、theme-color 与页面描述，标题改为「运营后台管理中心」
 2026-10-21 22:10:33 +08:00
yml2213 ef36453694 feat(dcauth): 移除机器码，改用纯设备码认证 
- DCAuth 协议升级到 v2，签名原文只含设备码；客户端 2.0.0，旧版本返回 426
- 删除客户端机器码采集、后端 machine_code_* 字段与日志、后台机器码展示
- 102 迁移在生产执行前直接改为无机器码结构；SQL 守卫仅放行该文件
- Mock 短信不启用每日限额；修复慢电脑首次启动的协议转发竞态
- 新增 macOS DCAuth.app 打包脚本，注册 dcauth:// 协议，浏览器可直接唤起
 2026-10-21 20:46:25 +08:00
yml2213 cb916d7750 feat(dcauth): 新增常驻托盘客户端与版本显示 
Windows 改为单实例托盘常驻，协议唤起只弹一个确认窗口；补充 macOS 后台守护进程
与客户端版本显示。
 2026-10-21 20:46:25 +08:00
yml2213 040100f290 feat(dcauth): 新增后台手机号与设备认证登录 
登录链路改为账号密码 + 短信验证码 + DCAuth 设备签名，并新增后台手机号绑定、
登录日志、设备绑定与重置接口。
 2026-10-21 20:46:24 +08:00
yml2213 111bc76357 feat(cost-center): 成本中心与商品映射开发草案 (含文档与订单页调整 WIP) 2026-10-20 10:01:52 +08:00
yml2213 7542d547bf feat: 新增客服备用金台账与后台用户中文显示名 
- 新增备用金账户、流水、支出、对账与权限
- 后台用户支持中文显示名并同步备用金姓名
- 审计、登录记录、任务及工单操作人优先展示中文名
- 补充备用金与人工支出方案文档
 2026-10-18 13:55:24 +08:00
yml2213 6850bc64ff feat(work-order): 发布并核销支持抖音券（按来源分流，抖音走 DYC 券核销） 2026-10-15 13:22:18 +08:00
yml2213 584b6f52aa fix(work-order): 问题单处置存在活跃拼单份额时禁止取消/退回大厅/重开 
生产实锤 WK26101503335487：客服对份额已提交的拼单母单走问题单处置-取消，
母单整单 cancelled 后份额验收/单人撤单全部被母单状态挡死，后台无补救入口。

- 抽出 getActiveWorkOrderShareCountWithClient 统一活跃份额统计口径
- resolveProblemWorkOrder 的 cancel/cancel_deduct/reopen 先过活跃份额防线
  （return_to_worker 不拦），返回结构改为 {order, failureReason}
- settleOverdueWorkOrder 复用同一统计函数，消除两份 COUNT 口径
- 服务层映射 409 work_order_problem_resolution_has_active_shares，
  文案引导客服先单独验收/单人撤单
 2026-10-15 10:34:43 +08:00
yml2213 10464fea89 refactor(product-match): 抽离接单模板匹配引擎（来源适配器/引擎/价格收口 + 后台按订单项试匹配） 
新增 services/product-match：来源适配器（kuaishou-91 合成 91+快手 / pdd / douyin-mashida）+ 平台无关匹配上下文 + 条件打分引擎（并列最高=ambiguous 不猜、逐维诊断）+ 价格数量拼单唯一实现。

- 商店键命名空间化（kuaishou:/pdd:/douyin:），店铺为可选作用域：留空即可按订单信息匹配
- 抖音匹配文本只取内部 SKU，引流标题只进 promoTitle，itemTitle 恒空（修复 0.85 元误命中碎梦浮光珍宝礼盒、拼单未开）
- work-product-match-mappers 改为门面（签名不变），work-order-pricing 改为转发
- 新增后台「按订单项试匹配」接口与面板：走发单同一套链路，返回模板/数量/单价/总额/拼单
- 生产样本回放：91/PDD 6000 条决策 0 差异；抖音 5 条全为修正

设计见 docs/接单模板匹配引擎重构设计.md
 2026-10-14 15:58:21 +08:00
yml2213 4b081d88c5 feat(douyin-mashida): 抖音按 SKU 三层分类接入（对齐 91/快手） 
- sku_code 恒为内部 SKU（不再被英文 sku 覆写）；英文 sku / 引流标题分别落 snapshot
- 命中映射 → affiliate_dash；未命中不再兜底 manual_dispatch（无执行载体 = 待人工，不建任务）
- 抖音映射支持「常量表 + 后台 skuMapping 增量」，新增商品不必发版
- 载体唯一守卫：命中自动发货的订单项不再建工单
- 券 cert_link 与命中解耦（/h5 一律按订单号拼）；券写入工单 material_json.douyinMashidaVoucher
- 新增/修正 16 例单测；后端全量 717 例 / 0 失败
 2026-10-14 13:00:49 +08:00
yml2213 e8fbb28cf4 feat(claim): 人工履约单领取页只显示「人工处理中，请等待客服」 
未命中 AFFILIATE_DASH_SKU_MAPPING 的抖音单显式回落 manual_dispatch（人工），这类单没有
自动发货通道（无 claim token、无绑定二维码），但卡券 cert_link 仍指向 /h5/<订单号> 领取页；
原页面会让买家「输 UID」，提交后没有任何自动发货动作，属于误导买家。

- 后端 kuaishou-cloud-claim-context.ts：新增 MANUAL_FULFILLMENT_MESSAGE 与
  resolveManualFulfillmentMessage(executorKey)（manual_dispatch → 等待话术，其它执行器空串）；
  三个 payload builder 统一输出 manualFulfillment / manualFulfillmentMessage
- 前端 claim-snapshot.ts：输出 isManualFulfillment / manualFulfillmentMessage，
  progressText 同步显示等待话术
- 前端 ClaimPage.tsx：在「渠道已下线」之后、「输 UID」之前插入人工单卡片（只读 + 刷新状态），
  人工单不会自动轮询（无 expectedUid → 不安排下一次轮询）
- types/claim.ts：补齐两个可选字段；话术只在后端维护一份，前端只做兜底

验证：后端 npm run check（701 单测）与前端 npm run check（格式/lint/类型/143 单测/构建）全绿
 2026-10-13 13:53:00 +08:00
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 7e197c9413 fix(frontend): H5 领取前缀整段接管，/h5 裸链接不再跳后台登录 
根因：公开路径判定原先只认「带参数」形态（isH5ClaimPath 只认 /h5/<orderNo>），
裸前缀 https://<域名>/h5（后台 claimLinkBase / certLink 的基址）判定不命中，
于是落回主站 HashRouter 被后台路由接管成
https://<域名>/h5/#/admin/dashboard 后台登录页。

- utils/claim-path.ts：isClaimPath / isH5ClaimPath 改为命名空间级判定（含裸前缀与多段路径），
  参数解析仍严格；新增 resolveH5ClaimOrderNoFromInput（纯订单号 / 整条链接 / 缺协议 /
  带后台残留 hash 都能取出订单号，只有前缀时返回空串）
- pages/claim/H5ClaimEntryPage.tsx：新增 /h5 领取入口页，买家输订单号或粘贴完整链接后
  跳 /h5/<订单号>，走与分享链接同一套领取流程
- App.tsx：H5ClaimApplication 接管 /h5 整段前缀（/h5 入口页、/h5/:orderNo 领取页、
  其它子路径回入口页）；useClearStrayHash 抹掉历史残留的 #/admin/dashboard
- tests/claim-path.test.ts：补齐裸前缀、相邻前缀 /h5x、粘贴链接解析等回归用例

验证：npm run check 全绿（prettier + eslint + tsc + 143 单测 + vite build）
 2026-10-13 13:42:06 +08:00
yml2213 5a73fb74a9 feat(douyin-mashida): 新增抖音券核销后台界面（列表/核销/冲正/同步/对账/作废） 
抖音订单并非纯自动发货：内部 SKU 命中 AFFILIATE_DASH_SKU_MAPPING 才走自动通道，
未命中显式回落人工，且核销依赖买家自己到 /redeem 输订单号。此前核销侧在后台完全
不可见：自动核销是 void .catch(warn) 只落日志，cancelVerify 出网方法已就绪但没有入口。

照快手电子凭证的骨架做一套抖音版（两张表两套状态机，不复用）：
- 券码状态、平台侧状态、同步错误全部可视化，支持只看同步失败
- 核销/冲正/重新同步/平台对账/重发券码/作废，每个写操作都带审计
- 券码列显示「核销实际会用的券码」（platform_cert_no 优先），平台改过名时额外标注
- 冲正先打平台 cancelVerify 再回退本地，避免本地与平台状态漂移
 2026-10-12 19:45:06 +08:00
yml2213 cb064d7cd5 fix(worker-platform): 工单号前缀改 WK 并在检索侧容错 O/0，彻底解决「按工单号搜不到」 
## 线上定位到的真正根因

客服搜 `WO26101213031939` 搜不到，但用同单的平台号 `2628501763808879` 搜得到。
到生产库核对后确认：

- 库里真实值 `work_order_no = WO26101213031939`（hex 574f… = 字母 O），状态 pending_acceptance；
- 用字母 O 的 SQL 分支 → 1 行；用数字 0（`W026101213031939`）→ 0 行；
- 全库 127,906 单**全部**以 `WO` 开头、`W0` 开头 0 单、字母 `o` 只出现在第 2 位。

即：前缀里的字母 O 被输成数字 0（`WO` / `W0` 在界面字体里几乎无法区分），
落进通配符分支后必然为空 —— 与前面几轮的「筛选把单藏起来」是两个独立成因，
这也解释了为什么改筛选逻辑一直没解决。

## 修法

1. 生成端换前缀：generateWorkOrderNo 产出 `WK…`（K 与 0 不会看混），从源头消掉歧义；
2. 检索端同时兼容三种写法（历史 WO 号无需迁移）：
   - isWorkOrderNoLookupKeyword 放宽为 `^W[oOkK0]…`；
   - 新增 buildWorkOrderNoKeywordVariants：W0→[W0, WO, WK]、WO→[WO, W0]、WK→[WK]，
     SQL 分支对每个候选下发「等值 + 前缀」条件（仍是索引条件，不会退化成全表扫）；
   - 前端 isExplicitOrderNoSearch 同步（否则面板不清理筛选、实时补丁护栏也不生效）；
3. 顺手加一层归一化：NFKC（全角→半角）+ 去零宽字符，前后端同一口径
   （normalizeLookupKeyword / normalizeSearchText），覆盖「粘贴带不可见字符」这类同族问题；
4. 寄卖匹配弹窗的占位提示更新为 WK... / WO...。

## 验证

- 后端 npm run check 全绿：692 tests（689 pass / 3 skip），新增
  work-order-keyword-lookup.test.ts 直接断言 SQL 参数与「不得出现前置通配符」；
- 前端 npm run check 全绿：139 tests；
- 既有用例 worker-platform-repo.test.ts 的期望值同步为新形态（两条候选条件）。
 2026-10-12 16:51:08 +08:00
yml2213 fe4d02d136 fix(worker-platform): 按工单号搜不到彻底收口 —— 显式单号检索不再被任何排他筛选吞掉 
## 修的是什么

线上反复复发的「后台接单平台按工单号搜不到、某些状态尤其明显」，根因不是一处，
而是同一类问题在 5 个地方各留了一半（历次修复都只补了一处，所以总复发）：

1. 状态筛选走运营态派生：拼单母单一旦有人参与，open → in_progress /
   pending_acceptance，于是「单号 + 待接单」永远为空（没人参与时反而搜得到），
   这正是「有人接单后就搜不到」；非拼单单子被接单后同理。
2. 「单号 + 接单人员 / 分类 / 打手等级 / 创建时间」照样过滤掉目标单
   （接单人员是 INNER JOIN 可见集合，不在集合里整行消失）。
   d6523635 只在面板查询按钮里清了 状态/赠送阶段/验收模式，这三个没清。
3. 待办通知跳转（buildNotificationActionPath 带 ?workOrderId=）设下的
   「定位工单」是 wo.id = X 排他条件，不手点「取消定位」就一直生效，
   之后搜任何别的单号都是空 —— 这条路径历次修复从未涉及。
4. AdminLayout 把服务端 operation='remove' 直接判成 mismatch，
   绕过了「显式单号不删行」的护栏。
5. 打手端「我的订单」默认页签固定「代练中」，搜索不联动页签、
   实时补丁又拿状态当可证伪条件删行 → 打手端同类问题（此前只修了关键词匹配）。

## 修法（收口到单一真源，不再按按钮打补丁）

后端：
- 新增 isExplicitOrderNoLookupKeyword()（工单号 / 平台单号 / SUB·INV·AS·DT）；
- 后台列表筛选抽成纯函数 resolveAdminWorkOrderListFilters()：显式单号检索时
  不下推 状态/VIP待补图/验收模式/赠送阶段/接单人员/分类/打手等级/创建时间/定位工单；
- 打手端 resolveWorkerMyOrderStatusFilter()：只放掉状态与 VIP 待补图，
  **严格保留 workerSharingId 可见范围**（否则打手能搜到别人的单）。

前端：
- admin-realtime-work-orders.ts：显式单号检索直接判 unknown（含服务端 remove），
  remove 的短路移交给判定函数；
- WorkOrdersPanel：单号检索时清空全部排他筛选并提示「已按单号精准检索，自动忽略…」，
  通知定位工单时也清掉其它筛选，避免残留；
- WorkerOrdersPage：单号检索自动切「全部订单」；WorkerLayout 走新的
  resolveWorkerMyOrderRealtimeVerdict()，与后台同策。

刻意不改（避免越权/召回不可用单）：抢单大厅（候选必须是 open）、
寄卖手动匹配候选（只做未接单整单）。

## 验证

后端 npm run check 全绿：682 pass / 3 skip（新增 6 项）；
前端 npm run check 全绿：138 pass（新增 6 项，含「单号检索 + 实时事件不得删行」，
以及「服务端 remove 不得绕过单号护栏」的回归）；format/lint/typecheck/build 通过。
无数据库迁移。
 2026-10-12 15:48:30 +08:00
yml2213 966b804bfc feat(worker): 保留超时订单买家资料与快捷复制功能以方便打手核对辨认 
- 调整目的：打手在订单超时退回大厅或被抢后，需要核对游戏内对应的好友与账号以分辨是哪一单，避免误认；
- 列表与抽屉展示：在桌面端表格、移动端卡片及详情抽屉中，恢复买家资料与主页截图展示，保留「复制信息」「复制图片」按钮，并补充「已超时，仅供核对辨认」轻量警示；
- 履约隔离：依然严格禁用一切提交验收、修改截图与申请取消等履约操作；
- 验证方式：通过前端 prettier、eslint、tsc、vitest、vite build 与后端全部 676 个测试。
 2026-10-11 15:39:10 +08:00
yml2213 c5e8b78a33 fix(worker): 修复打手订单可见范围查询中参数类型推导不兼容错误 
- 显式类型转换：在 worker_visible 的 4 个 UNION 分支中，为 workerSharePlaceholder 显式补充 ::bigint 与 ::text 类型转换；
- 避免类型推导冲突：消除由于 JSON 字符串比较导致的 bigint = text 操作符缺失错误（operator does not exist: text = bigint）；
- 验证方式：在 PostgreSQL 容器中验证 PREPARE/EXECUTE 与在后端容器内实测 listWorkOrders 正常返回 20 条记录。
 2026-10-11 15:25:48 +08:00
yml2213 9ce29964c7 style(frontend): 格式化前端代码并修复 eslint 异步操作未标记告警 
- 统一 prettier 代码风格；
- 为 AdminTaskDetailPage 与 AdminTasksPage 中未捕获的 Promise 添加 void 标记；
- 验证方式：npm --prefix apps/frontend run check 全流程通过。
 2026-10-11 15:20:54 +08:00
yml2213 6012add3c9 feat(worker): 打手接单界面支持查看超时历史订单并增加安全免责警示 
- 数据库与查询层：通过索引 idx_work_order_events_timeout_worker_id 关联打手历史 timeout 事件与取消的拼单份额，打手在退回大厅或被他人抢走后仍能在「已超时」tab 查看历史记录；
- 状态与权限管控：针对超时工单将个人端状态稳定映射为 open，报酬与冻结押金置为 0，彻底禁用上传图片、提交验收、好友资料、申请取消等履约操作；
- 风险防护与免责说明：列表与抽屉详情顶部增加醒目的免责声明与警示横幅（告知订单已退回大厅或被他人接手，严禁在游戏内继续赠送，造成的损失平台概不负责）；锁定买家游戏资料与快捷复制；
- 验证方式：通过后端全部 676 个测试、typecheck、check:sql 及前端 check（eslint、vitest/node:test、tsc、vite build）。
 2026-10-11 15:20:46 +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 06d888fb6f fix(products): 恢复官方正版商品图并统一渠道代码格式化 
- 从上游系统同步官方原始高清商品图（lucky_coin_x2/x30/x90），剔除此前劣质变形的合成图
- 验证全量 40 款商品资产与 affiliate_dash 官方权威库 100% 逐字节对齐
- 任务详情页接入 formatGameChannelLabel 统一渠道展示逻辑（1-1 -> 安卓-微信）
- 验证方式：npm run build、npm test（674 自动化单测全部通过）
 2026-10-10 21:34:59 +08:00
yml2213 87f6f13995 fix(asset): 区分幸运币 x2、x30、x90 对应规格金币立绘 
- lucky_coin_x2.webp: 金币徽章 + x2 数量角标
- lucky_coin_x30.webp: 金币徽章 + x30 数量角标
- lucky_coin_x90.webp: 金币徽章 + x90 数量角标
- 保持字体、斜度、色彩与边角透明度一致
 2026-10-10 21:28:48 +08:00
yml2213 ed8bdf399d fix(voucher): 替换幸运币纯净无水印透明底素材并统一区服渠道中文转换 
- 将幸运币 2/30/90 个 webp 素材替换为纯净 RGBA 透明金币立绘，消除白底多边形及「幸运币礼包（小）」文字水印
- 增加 formatGameChannelLabel 转换函数：将腾讯/DLC area-plat 协议代号（如 1-1）统一转换为用户友好的「安卓-微信」
- 领取页第 2/3/4 步与凭据大图全局统一应用区服中文转换
 2026-10-10 21:18:31 +08:00
yml2213 f3f2550b19 feat(admin): 彻底优化任务列表与详情界面，集成到账存证凭单与联盟直充面板 
- 优化任务列表角色列：支持从 affiliateDash 及 claimIdentity 中自动提取并展示角色名与 UID（含一键复制）
- 列表操作栏支持一键查看到账存证凭单，支持直接复制图片发给买家或下载保存
- 任务详情页全面现代化重构：
  - 新增「兑换成功 · 官方直充到账存证凭据」大卡片，实时生成 640x960 Retina 高清卡片，支持一键写入系统剪贴板（微信/QQ/客服窗口直接 Ctrl+V 发送）、下载 PNG 大图与全屏预览
  - 新增「联盟直充履约 (affiliate_dash)」专属面板，结构化展示上游订单号、直充状态、点数积分、核销状态及供应商回执
  - 优化凭据生成器 (voucher.ts)：强制优先读取本地高清商品图，彻底消除上游图片文字水印与圆环破图问题
- 验证方式：npm run build & npm test (133 项单测全量通过)
 2026-10-10 21:04:01 +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 c137741215 feat(frontend): vite 白名单放行 sakurafrp 域名后缀 2026-10-10 20:34:24 +08:00
yml2213 73de90ea4f fix(admin): 平台推送地址优先回显已配置的公网域名 
- 引入 resolveDouyinMashidaPublicOrigin 从已配置的 claimLinkBase/certLink 提取公网域名
- 更新后台面板 message_url 展示逻辑，即使从 localhost 访问也清晰呈现已配置的公网推送地址
- 向平台订阅推送时使用已解析的公网域名，避免错误推送 localhost
- 补充前端单元测试并通过全量构建校验
 2026-10-10 20:18:23 +08:00
yml2213 fa1a67a03d chore(vite): dev server 允许 ngrok-free.dev 域名访问 
验证方式：ngrok 静态域名下直连自检通过，HTTP 状态 200 正常
 2026-10-10 20:15:16 +08:00
yml2213 ccf8de97a9 chore(douyin-mashida): 联调脚本适配 /h5 路径与统一后台接口调用 
- set-public-url 脚本将 certLink 与 claimLinkBase 统一设置为 <公网地址>/h5
- subscribe 脚本改走后台 HTTP 管理接口，避免在宿主机执行时直连数据库导致连接异常

验证方式：ngrok 隧道下端到端执行 subscribe 与 preflight 自动化校验全部通过
 2026-10-10 20:12:33 +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 748c18bc7d feat(order): 精准区分自动直发与接单平台打手履约，智能门控H5直充按钮 
- 后端增加按订单批量关联接单工单查询，精准识别履约类型（自动直发 / 打手履约 / 电子凭证 / 拼多多发货）
- 订单列表与详情页中，仅当订单为自动直发（affiliate_dash / 码速达直充）时展示【H5】一键复制直充链接与兑换状态控制
- 接单平台工单单与纯核销单隐藏直充 H5 按钮与兑换暂停/关闭标签，防止客服向打手单买家误发直充链接
- 交付模式标签升级为「⚡ 自动直发」、「👥 打手履约」、「🎫 电子凭证」、「📦 拼多多发货」

验证方式：前端类型检查与打包构建通过，全量 132 项前端单测与 674 项后端单测全部通过
 2026-10-10 19:44:20 +08:00
yml2213 9a6b4313a8 fix(order): 移除订单列表冗长的买家信息列，优化多平台表格密度 
- 移除订单列表中的「买家信息」列，消除抖音等虚拟品类中超长加密 open_id / 匿名买家造成的垂直与水平排版挤压
- 紧凑化表格宽度（scroll 960px），提升列表浏览效率
- 详情页继续保留完整买家原始载荷供追溯

验证方式：前端类型检查及 132 项单测全通过，前端打包构建通过
 2026-10-10 19:04:09 +08:00
yml2213 03020e85c7 feat(order): 订单列表页UI重构与多平台(快手/91卡券、抖音、拼多多)适配 
- 顶部新增平台快捷分流器（Segmented），支持「全部 / 快手·91卡券 / 抖音码速达 / 拼多多 / 本地模拟」一键筛选
- 重构订单表格列布局为平台与订单号、买家信息、商品规格、交付与履约状态、金额与支付时间、快捷操作等现代化字段
- 优化快手与 91卡券业务归集逻辑，统一数据查询与徽标显示口径
- 增强订单行快捷操作，支持一键复制 H5 领取链接与查看详情

验证方式：后端 674 项单测全通过，前端 132 项单测全通过，前端打包构建通过
 2026-10-10 18:54:40 +08:00
yml2213 3f2bb3f09a fix(admin): 修复恢复启用订单兑换时 orderId 闭包失效及 H5 页面重试机制 
- 修复任务详情页和订单详情页中 statusMutation 闭包提前捕获空 orderId 导致恢复启用请求未发出的问题，改为动态从 query.data 解析最新的 orderId
- 订单详情页统一切换为 App.useApp 提供的 modal/message 实例，保证异步弹窗与提示稳定渲染
- H5 买家领取页面在暂停或关闭等异常状态卡片中增加【重新检测状态】按钮，客服恢复启用后买家可一键重新加载最新状态
- 验证方式：前端类型检查（0 error）、单测 132 项全通及前端 Vite 重新构建成功
 2026-10-10 18:46:49 +08:00
yml2213 6971002579 feat(admin): 履约完成或终态时自动隐藏暂停与关闭兑换按钮 
- 任务详情页（AdminTaskDetailPage）：若任务已履约完成（completed/delivered/success）或订单已完成/已退款，自动隐藏【暂停兑换】和【关闭兑换】按钮，避免误操作
- 订单详情页（AdminOrderDetailPage）：若订单下任务已全部履约完成或订单终态，同样自动隐藏【暂停兑换】和【关闭兑换】
- 针对已被暂停/关闭的历史订单，始终保留【恢复启用】入口以便误操作时补救
- 验证方式：前端类型检查（0 error）、前端单测 132 项全通及前端 Vite 重新构建成功
 2026-10-10 18:42:12 +08:00
yml2213 9b29f7513a fix(frontend): 修复 AdminTaskDetailPage 中 useMutation 的 Hook 调用顺序 
- 将 useMutation 提升至组件顶层，避免因位于 query.isLoading 等早期 return 分支之后导致 React Hooks 顺序变动报错
- 验证方式：前端类型检查（0 error）、单测 132 项全通及前端 Vite 重新构建成功
 2026-10-10 18:40:07 +08:00
yml2213 122144a2b7 feat(task): 任务详情与列表页增加H5订单号领取链接及兑换有效性控制 
- 后端 AdminTaskDetail 视图补充关联订单的 claimStatus、claimStatusReason 等状态字段
- 任务详情页升级“领取链接”卡片：支持固定 H5 链接展示、状态标签（有效/暂停/关闭），并支持一键复制及【暂停/关闭/恢复启用】弹窗操作
- 任务详情页保留历史 Token 链接作为辅助对比展示
- 任务列表页在平台订单号旁增加一键复制 H5 领取链接的快捷按钮
- 验证方式：前后端类型检查、全量单元测试（后端 674、前端 132）及前后端全量构建均通过
 2026-10-10 18:38:49 +08:00
yml2213 412d219cca feat(claim): 支持固定H5订单号领取与订单兑换有效性后台控制 
- 数据库新增 099_order_claim_status.sql 迁移，扩展 claim_status、claim_status_reason 等字段
- 后端新增 /claims/h5/:orderNo、UID提交、分销提交接口，保留原有 token 接口双轨兼容
- 增加兑换有效性强拦截：暂停/关闭/退款/取消订单精准阻断并返回友好提示
- 后台新增 POST /admin/orders/:orderId/claim-status 接口与审计日志记录
- 前端管理后台（订单列表、详情页）支持 H5 兑换状态展示、一键复制链接及暂停/关闭/启用弹窗
- 前端领取页面适配 /h5/:orderNo 路由及暂停/关闭等状态的异常展示
- 验证方式：运行前后端类型检查、全量单元测试（后端 674、前端 132）及全量构建编译均通过
 2026-10-10 18:05:46 +08:00
yml2213 2d727a6797 fix(worker-platform): 修复对已冻结打手调级时误报冻结原因必填的问题 
- 做了什么：
  1. 后端 reviewAdminWorkerUser 中优化 freezeReason 校验条件：区分是否为新变为 rejected 状态，若账号原本已处于冻结态且本次仅调整等级未变动状态，直接沿用已有冻结原因，不再强制要求传 freezeReason；
  2. 前端 submitLevel 在提交调级时补充传递打手既有的 freezeReason；
  3. 后端新增对应测试用例确保后续回归。
- 为什么：
  当打手处于冻结状态（rejected）时，管理员对其执行调级操作因未携带 freezeReason 触发了冻结原因校验错误，导致调级失败。
- 验证方式：
  运行 npm run check（671 项测试全绿，类型与构建检查通过）。
 2026-10-10 13:51:58 +08:00
yml2213 85fc2eaa7c feat(worker-platform): 支持后台人工调级锁定等级与解除自动升级限制 
- 做了什么：
  1. 新增数据库迁移 098_worker_level_lock.sql，在 worker_users 表增加 is_level_locked、level_locked_at、level_locked_reason、level_locked_by 字段；
  2. 后端自动升级函数 maybeUpgradeWorkerLevelWithClient 和判定函数 shouldApplyAutomaticWorkerLevel 增加 is_level_locked 守卫，被锁定的打手跳过自动升级；
  3. 后台打手审核调级服务 reviewAdminWorkerUser 支持等级锁定参数与变更记录，人工调级时自动写入 worker_level_logs 流水，并提供 updateAdminWorkerLevelLock 专用接口；
  4. 前端打手列表等级列展示「已锁定」状态及 Tooltip 原因，调级弹窗支持「锁定自动升级」开关与原因输入，操作列提供「解除限制」快捷操作；
  5. 打手详情抽屉补充展示等级锁定说明。
- 为什么：
  解决打手被人工调整等级（如 VIP5 调至 VIP4）后，因历史累计完成单数满足门槛导致后续结算再次自动升级回高等级的问题，并支持后续随时解除限制恢复自动升级。
- 验证方式：
  1. 后端新增 shouldApplyAutomaticWorkerLevel 与 mapWorkerUser 单元测试，运行 npm run check（670 测试全过，类型与 SQL guard 验证通过）；
  2. 前端新增 worker-level-lock.test.ts 单元测试，运行 npm run check（130 测试全过，typecheck 与 build 验证通过）。
 2026-10-10 13:44:57 +08:00
yml2213 687bb40db1 fix(migrations): 已应用的迁移文件不能删除（否则服务起不来） 
上一轮纠偏时我把迁移 096（`claim_submission_json`）从文件系统删掉了，只留新的 097 去 DROP 列。
结果 `node-pg-migrate` 的排序校验直接拒绝启动：

  Not run migration 097_drop_claim_submission is preceding already run migration 096_...

因为数据库里已记录 096 已执行、而文件系统里没有它。后端因此进入重试循环、`/health/ready` 一直 503
（生产同样会中招，属于启动阻塞）。

正确做法：**保留 096 文件**（结构演进留在历史里），用 097 承担「删列」这一步；
两边的 `schema_migrations` 记录都完整，已应用 096 的环境与全新库都能正常迁移。

同时**还原 `check-sql-guard.ts` 为严格版**：既然不需要删迁移了，就不该放宽守卫
（原规则「历史迁移只能新增、不可修改/删除」继续生效，实测通过）。

实测：恢复后启动日志正常执行 `097_drop_claim_submission (UP)`、`/health/ready` 200、
`fulfillment_tasks.claim_submission_json` 已删除；`npm run check` 671/668/0 全绿。
 2026-10-09 19:10:31 +08:00
yml2213 1339c6887e refactor(claim): 删除自建皮肤领取页，路径式 /claim/<token> 复用现成领取页 + 物品图片 
**删掉上一轮自建的领取页**
- `pages/claim-skin/*`、`services/claim-skin.ts`、`types/claim-skin.ts`、`tests/claim-skin.test.ts`
  及其样式（client.css 里 `.claim-skin-*` 整段 254 行）
- 后台我加的展示项：「皮肤自动发货」筛选项、执行器标签、「买家提交信息」卡片

**路径式链接复用现成领取页**
- `utils/claim-path.ts`（中性命名 `isClaimPath` / `resolveClaimToken`）+ 单测
- `App.tsx`：pathname 命中 `/claim/<token>` → 独立 BrowserRouter 渲染**现成的 `ClaimPage`**
  （页面零复制零改动：它只用 `useParams`，不读 hash）；`#/claim/:token` 仍走主站 HashRouter，
  两者互不影响，且有用例断言 hash 入口不命中路径判定

**物品图片**
- 后端领取详情的 `product.imageUrl` 接上（内部 SKU 在 `spec_json.code` / `sku_code` /
  `sku_name` 哪个字段都能回退找到图，映射不到返回空串）
- 领取页新增 `ClaimProductImage`：居中大图（宽度 min(220px,62%)、圆角 16px），
  空值或加载失败都降级虚线占位块，不出现破图

`npm run check`：前端 128 / 128 全绿（去掉旧用例 17 个、新增路径与图片用例）
 2026-10-09 16:13:46 +08:00