dachui/order_site
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
1,227 Commits 8 Branches 0 Tags
6cd6401eca10ad485ca63004a7cd8e876775e092
Commit Graph
323 Commits
Author SHA1 Message Date
yml2213 65b7f4f9dc refactor(finance)!: 强制渠道模型，移除旧履约方式与同步链路 
- 删除 fulfillment_mode 相关的旧同步/回填链路与定时任务
- 删除 cost_finance_sync、成本快照同步、人工商品归一等遗留服务
- 迁移 113 直接删除 order_items.fulfillment_mode 及其索引约束
- 断代脚本自带归档步骤，不再依赖独立回填脚本
- 退款/事实/总账统一走渠道版销售事实
 2026-10-31 19:52:03 +08:00
yml2213 75a3801236 feat(scheduler): 六个财务管道作业，模板改价即同步成本版本 
- channel_assign / carrier_dispatch / product_normalize / cost_snapshot / sales_facts / ledger_post
- 每个作业只写自己那一层，失败互不影响，可单独启停
- 接单模板保存后自动同步规则级成本版本，失败不阻塞模板保存
 2026-10-31 18:12:19 +08:00
yml2213 22400fbec6 fix(worker-platform): 资料更新不再覆盖并发抢单状态 2026-10-31 11:29:53 +08:00
yml2213 44791a9c8b perf(worker-platform): 排行榜公共缓存与抢单短路，压制 8.5s 慢查询脉冲 
- 排行榜：Top 10 改为按 period 全局共享缓存（TTL 30s），SQL 传 currentWorkerId=0；
  个人单数解耦为 assigned_worker_id 精准索引查询（TTL 15s），未上榜展示「暂未上榜」，
  消除「每个打手一份缓存」导致的 8.5 秒全表聚合穿透；
- 抢单短路：新增 work-order-grab-guard，对已关闭工单打 10s 进程内标记，命中直接 409；
  publishWorkOrderRealtimeChange 统一作废标记，避免撤单/超时重开/重新发布后误杀正常抢单；
- 我的订单：默认排序也走「先取 id 再批量回表」的延迟分页，避免宽列 material_json 参与排序；
- 文档：新增生产 CPU 波动分析报告，慢查询数字按 6,235 行日志实测重算，并标注修复状态与验收口径。

验证：typecheck / check:sql / eslint / prettier 通过；后端 npm test 914 项（910 pass、4 skip、0 fail）。
 2026-10-30 22:42:11 +08:00
yml2213 96ae744dbb fix(worker): 验收重复提交幂等，修复卡待验收与手动验收 500 2026-10-30 21:33:56 +08:00
yml2213 fb485f7e36 feat(risk-control): 新增 IP/账号手动封禁，并收口财务同步的全表更新 
- 风控：worker_risk_bans 表 + 前置封禁中间件（登录一并拦截）+ 后台列表/新增/解封
- 财务：成本快照补商品维度收口到本批 order_item_id，不再整表扫 899MB 的 order_items
- 性能：order_items 覆盖索引（迁移 110）、大厅 pageSize 上限 20、已读/上传接口限流
 2026-10-30 20:15:14 +08:00
yml2213 1b170d3f45 perf(worker-platform): 店铺筛选下拉加 5 分钟缓存，避免全表扫描拖垮生产 2026-10-30 19:30:56 +08:00
yml2213 c7d650b482 fix(worker): 售后追缴自动驳回提现并扣冻结资金，修复欠款抵扣 500 
- 修复欠款抵扣 SQL 参数类型冲突（debt_amount = $1 与 $1 = 0 推断不一致），
  此前手动偿还、验收报酬抵扣、充值/押金解冻/寄卖自动抵扣都会 500
- 追缴顺序改为 待解冻押金 → 提现冻结 → 可用余额 → 欠款：
  驳回待审核提现并直接扣走冻结资金，扣不完的部分退回可用余额
- 迁移 109：售后单记录 withdraw_deduction_amount，补 pending 提现部分索引
- 新增流水类型 after_sales_withdraw_deduction，前后端展示与标签同步
- 提现驳回退回余额后补调欠款自动抵扣，与充值/结算/解冻/寄卖路径对齐
- 补追缴分配单测与 SQL 参数类型静态门禁
 2026-10-29 19:05:37 +08:00
yml2213 979a1bfa41 fix: 免审验收容错与成本中心归一回填超时修复 
- worker：等级升级计数移出验收事务，瞬时错误重试一次，最终失败转人工待办且不再返回 500
- worker：待验收阶段修改验收资料时保留 reviewMode/evidenceStatus/evidenceDueAt
- cost-center：迁移 107 新增人工待归一覆盖部分索引（生产实测候选聚合 19.6s → 391ms）
- cost-center：归一人工商品/按工单回填商品/模板预览前端超时放宽到 300s
- cost-center：批处理接口语句超时放宽到 60s（SET LOCAL，在线接口仍为 15s）
 2026-10-29 14:33:35 +08:00
yml2213 9d5af359fa feat(finance): 完成财务控制、L1 钱包硬化与迁移收敛 
- P0/P1：影子总账追加调整、关账/退款/资金/积分幂等、成本版本追溯、对账订单项维度
- 迁移收敛：原 103–114 合并为 103_finance_foundation、104_finance_controls、105_work_order_consignment
- 数据：L1 钱包 BIGINT/CHECK/奖励幂等；重复奖励审计口径修正与人工核对清单
- 报表：销售毛利缺失成本收入提示，旧收支页明确现金流口径
- 文档：同步迁移基线、合并评估、代码复核与上线说明
 2026-10-27 16:08:16 +08:00
zhaoxing a53321ef30 feat:寄卖增加对接客服，db脚本迁移修复 2026-10-27 13:56:08 +08:00
zhaoxing 622bd779dd feat:寄卖增加对接客服，db脚本迁移修复 2026-10-27 13:39:48 +08:00
zhaoxing 7743d2019c fix:优化再拼一次bug,优化打手端移动端拼单列表显示 2026-10-26 16:36:26 +08:00
yml2213 f0dda3842b test(worker): 校验拼单验收统一收口函数的寄卖钩子 2026-10-26 15:51:38 +08:00
zhaoxing 2bfcdd5b1f Merge branch 'dev1023' into dev 2026-10-26 15:26:43 +08:00
zhaoxing 2c9f741873 fix:撤单之后 重新指派给你同一个打手 同一个订单 不显示订单号不显示任何信息 2026-10-26 12:41:07 +08:00
zhaoxing 6a5a8d70b0 feat:拼单订单新增一个取消部分的按钮功能，点击之后，打手进行中和待接单的都会取消订单 2026-10-26 12:15:52 +08:00
yml2213 31a8b6fc65 Merge branch 'dev1023' into dev 
解决 9 个冲突文件，并修复合并后遗留问题：

- 大厅候选集：采用 FIFO 窗口 + 全部置顶单 UNION（列表与抢单/拼单复核同源）
- 拼单份额：采用多次参与模型（每次参与 INSERT 新份额、requestId 幂等），
  取消后可重新参与；移除 HEAD 已废弃的单行 rejoin 逻辑与对应测试
- 工单迁移与成本中心 103–108 编号撞车：合并重写为
  109_work_order_share_participation / 110_work_order_hall_and_shop_indexes；
  临时库全量执行与重跑幂等验证通过（10 列、唯一键已删、7 个索引）
- 实时补丁：保留个性化字段、置顶重排、分页总数同步；补回 orderTimelineVisible 类型
- 打手大厅：保留 memo 组件化，移植「再拼一次」多份额按钮逻辑
- 全项目表格统一 PercentTable：WorkerOrderShareTable 改造

验证：backend typecheck/lint/check:sql/test(833 pass)、
frontend typecheck/lint/test(172 pass)/build 全绿。
 2026-10-26 12:10:53 +08:00
zhaoxing 60fe00b28c fix:打手端/我的订单/验收：验收视频和验收图片至少上传一个就好了，其他逻辑按照上传图片走 2026-10-25 16:45:38 +08:00
yml2213 b7ad69831a feat(cost-center): 统一商品成本中心为全系统唯一标准价格源并闭环改价与工单同步 
- 核心架构：将商品与成本中心确立为全系统唯一标准价格源，接单模板价格在接单平台禁止编辑并提示收敛至成本中心，后端 saveAdminWorkProductRule 严格拦截价格篡改
- 改价与同步：标准商品目录与自动发货专属面板提供统一改价弹窗，支持追溯/立即生效/指定时间；改价后自动或手动将新价格同步至接单大厅待抢单工单，保持下游业务一致
- 缺陷修复：修复 cost_versions 追溯改价时因同生效时间违反 chk_cost_versions_period 检查约束及 uq_cost_versions_scope 唯一索引冲突的问题，采用 active 版本就地更新机制
- 分类树优化：工单二级分类树限定仅在工单来源展示，自动发货与人工客服彻底隐藏分类树并重置过滤条件
- 验证方式：通过后端 784 项全量测试、前后端 tsc 类型检查及前端生产构建打包
 2026-10-25 15:21:34 +08:00
zhaoxing 9c620d39cb feat:拼单明细管理加一个撤份额的功能，指定数量 2026-10-25 13:44:34 +08:00
yml2213 ccc71e0aab Merge branch 'main' into dev 2026-10-25 13:33:05 +08:00
yml2213 2fb7aae13f feat(auth): 登录态改为滑动续期（后台 24h/7d，打手 7d/30d） 2026-10-25 13:28:58 +08:00
yml2213 81edf530db fix(worker-platform): 拼单取消后可重入，大厅置顶始终优先 2026-10-25 13:08:19 +08:00
zhaoxing a7a8634a96 feat:加一个网站发布公告会弹出来点确定我已知晓的弹窗;mock数据自动匹配接单模板;本地访问模式修改 2026-10-25 12:27:32 +08:00
yml2213 465a9f65dc Merge remote-tracking branch 'gitea-aliyun/main' into dev 2026-10-25 11:14:12 +08:00
yml2213 7fdef88ba6 perf(worker-hall): 优化百单大厅加载与渲染性能 2026-10-24 20:41:58 +08:00
zhaoxing 0ee5554f57 add:新增验证视频可选上传功能 2026-10-24 16:12:56 +08:00
zhaoxing f9aeece7ab add:新增同一个工单同一人可以多次拼单：拼单明细ui优化 2026-10-23 17:45:05 +08:00
zhaoxing 7e1e1f7075 add:新增同一个工单同一人可以多次拼单：拼单后按钮固定显示「再拼一次」 2026-10-23 16:37:59 +08:00
zhaoxing 2befb57ef8 add:新增同一个工单同一人可以多次拼单：拼单后台撤单，不影响母单状态 2026-10-23 15:20:14 +08:00
zhaoxing 1d5615f1ae add:新增同一个工单同一人可以多次拼单 2026-10-23 15:14:07 +08:00
zhaoxing bfd2325ac5 add:新增同一个工单同一人可以多次拼单 2026-10-23 14:26:41 +08:00
yml2213 5d1ba11523 feat(finance): 统一履约事实并改造人工账单分类 2026-10-23 13:35:48 +08:00
yml2213 7c8832078f feat(finance): 接单模板发单金额落规则级成本版本 
此前接单平台成本版本只有 sys_work_order_reward 的全局 0 元占位，662 个模板的发单金额从未进入 cost_versions。\n\n现在为 662 个模板各生成一条规则级版本：634 条固定发单金额 + 28 条按件单价；全局 0 元版本仅作“按工单实际结算”占位。成本版本页新增“用户实付均价”和“平均实发/项”，支持按模板名称/规则键搜索，按商品筛选也能命中规则版本。\n\n历史工单快照关联到对应模板版本；模板保存时自动同步单条成本版本；删除模板会先把历史版本脱钩停用，保留快照可追溯。\n\n新增迁移 112 覆盖索引，用户实付聚合从约 1.1s 降到约 150ms。
 2026-10-22 19:29:53 +08:00
zhaoxing 067d54fdd8 接单平台：新增店铺筛选条件 2026-10-22 14:45:40 +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 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 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 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 893388b37f feat(consignment): 寄售仓库在库列表增加通过审核入库时间并在手动匹配中补全时间展示 
- 寄售仓库 (ConsignmentInventoryPanel)：表格中增加「通过审核入库时间」列并格式化展示，详情弹窗规范化展示入库时间、出库时间与提报时间
- 手动匹配弹窗 (ConsignmentManualMatchModal)：候选订单列表展示工单创建时间，顶部横幅与已选概要展示现货入库时间及订单创建时间；从订单匹配现货时展示现货入库时间
- 内部匹配接口与工单拦截：后端 listInventoryMatchableOrders 返回工单创建时间及平台单号；发布拦截弹窗中增加展示现货入库时间
- 验证方式：运行前后端单元测试全部通过，前端 build 校验通过
 2026-10-08 15:41:23 +08:00
yml2213andCursor 250c456a46 fix(consignment): 内部库存履约后不再把买家资料暴露给上一手打手 
退回大厅留下的 last_assigned 在状态离开待接单后会重新可见。履约时摘掉上一手，并清掉已经漏出的内部现货工单。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-10-05 19:18:43 +08:00
yml2213andCursor eae78aae34 fix(consignment): 退库后不再带出上一单买家资料，撤单清掉上一手验收痕迹 
现货退回仓库后只留卖家提报，不再挂买家角色、赠送凭证和店铺；工单撤单、退回、抢单时清掉验收与备注，买家下单资料仍保留。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-10-05 14:55:42 +08:00