dachui/order_site
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
948 Commits 6 Branches 0 Tags
9298b31b9b2f1efd43f9dd7f2a87b4ce5aa97b4d
Commit Graph
235 Commits
Author SHA1 Message Date
yml2213 cb8b249e57 feat(worker-platform): 实现打手寄卖白名单权限控制与存量发布打手平滑过渡 
1. 新增数据库迁移 082_worker_consignment_whitelist.sql，worker_users 表增加 can_consign 与 consignment_activated_at 字段，存量在 consignment_submissions 提报过的打手默认自动开启；
2. 打手端提报接口 publishWorkerConsignment 增加白名单权限服务端强校验拦截（403 consignment_permission_required）；
3. 管理后台打手管理表格增加「寄卖权限」实时 Switch 开关列与打手详情抽屉权限展示，支持客服即时开通或关闭打手寄卖权限；
4. 打手端我要寄卖页面在未开通权限时展示专属白名单引导卡片，一键呼起联系客服开通寄卖弹窗；
5. 补充寄卖权限拦截与路由单测，前端59项单测与后端507项单测全部通过。
 2026-09-21 13:30:33 +08:00
yml2213 c115f5e944 fix(claim): 修复后台手动关闭任务后领取链接未失效的缺陷 
1. 鉴权层激活 CLAIM_TERMINAL_STATUSES：在 getClaimContext 中增加 task 状态校验，对 closed 与 expired 终态任务实施 410 拦截并自愈更新关联 Token；
2. 仓储层新增 closeClaimTokensByTaskId()：支持按 taskId 批量更新所有非 closed 状态的 Token 为 closed，彻底杜绝多 Token 或重发链接导致的历史活跃残留；
3. 后台关闭任务流程闭环：closeAdminTask 显式触发 closeClaimTokensByTaskId，确保任务关闭时关联领取链接立即失效；
4. 补充 CLAIM_TERMINAL_STATUSES 单元测试与完整排查分析方案文档。
 2026-09-20 14:06:48 +08:00
yml2213 f07e4087ad feat(consignment): 优化寄售仓库与接单工单双向手动匹配，支持工单号与提报单号检索与强制匹配 
1. 寄售仓库手动匹配订单扩充支持 open 状态工单，增强 WO 工单号与纯数字的模糊/前缀搜索，修复工单搜不到的问题并在卡片高亮展示内部工单号与状态；
2. 接单工单操作列全面支持【手动匹配寄售】，允许从接单工单主动调起寄售匹配弹窗；
3. 寄售现货筛选支持通过 SUB 提报单号、INV 仓库号、供货打手等快速搜索；
4. 完善规格冲突下的强制匹配确认与必填原因提交机制，确保履约全流程留痕合规。
 2026-09-19 17:59:05 +08:00
yml2213 2c120bd3e5 fix(worker-platform): 接单平台工单详情抽屉完整展示寄售手动匹配与指派订单的卖家资料 
1. 修复管理后台「接单平台 -> 接单工单」抽屉中，手动匹配或指派寄售库存履约的工单因 booster_material_json 为空导致卖家资料全部显示 '-' 的问题；
2. 后端在履约及指派时将卖家角色昵称、数字ID、联系方式、手机号、备注及上架凭证截图完整写入工单 material.consignment；
3. 后端工单查询及展示映射层增加自动回退与批量库存补充解析机制，确保历史与新增的寄售工单均能准确解析出卖家角色名、ID、区服、系统与截图；
4. 前端工单抽屉卡片优化寄售订单的资料展示与阶段标签，清晰展示卖家角色名、游戏ID、联系方式（微信/QQ/手机）、提报/仓库单号及上架截图。
 2026-09-19 14:33:56 +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
yml2213 439888631f fix(worker-platform): 内部寄售现货履约发单金额对齐寄卖成本价并补充留痕追溯 
1. 内部现货履约时原子更新工单 reward_amount 为寄卖结算成本价，解决工单列表显示旧规则价与寄卖成本冲突问题；
2. 工单资料 material.consignment 与工单事件 flow 补充 previousRewardAmountFen/updatedRewardAmountFen/costPriceFen 等价格变更留痕；
3. 撤销寄售履约且退回未指派状态时支持自动还原原工单发单金额并在撤销事件中记录还原明细；
4. 新增 consignment-fulfillment-price-trace.test.ts 专项单测并通过全量测试回归。
 2026-09-19 10:22:09 +08:00
yml2213 d6523635ea fix(worker-platform): 优化工单号精准检索与跨状态流转展示，修复状态更新后工单消失问题 
1. 后端查询重构：新增 isWorkOrderNoLookupKeyword 工单号前缀与忽略大小写精准索引匹配，优化后端 work-order-query-repo 的工单号检索路径；
2. 前端单号智能穿透：管理员输入 WO... 等精准单号查询时，自动放宽细粒度排他状态/阶段过滤，避免加好友/验收等状态流转后工单因旧状态筛选脱靶消失；
3. 搜索栏交互升级：输入框清空即时重置关键词与页码，支持回车/按钮/清除全方位无缝触发；
4. 详情抽屉与多面板联动：增加 ordersQuery 数据更新对 detailOrder 的自动同步，并将 refreshAll 广播范围覆盖至寄售仓库与统计指标。
 2026-09-18 19:36:17 +08:00
yml2213 c17b8a78d5 fix(worker-consignment): 修复卖家提交赠送截图后在接单平台无法回显的问题 
1. 后端 listWorkerConsignments 接口从关联工单验收资料中提取 giftEvidenceImages、giftEvidenceNote、giftEvidenceSubmittedAt 并在打手端寄卖列表中下发；
2. 接单平台「我的寄卖」卡片新增已提交赠送凭证展示模块，支持展示缩略图、张数统计、大图预览及赠送备注；
3. 优化提报单与库存、工单的 SQL 关联兼容双向绑定，确保后台与前台均能稳定查到赠送凭证。
 2026-09-18 18:35:15 +08:00
yml2213 c5d1e2c375 feat(consignment): 寄售匹配成功后向卖家端与客服后台透出买家加好友资料 2026-09-17 20:46:45 +08:00
yml2213 103299a7c9 feat(consignment): 发布寄卖自动从接单模板带出建议价 
- 新纯函数 suggestConsignmentPriceFromRules：模板商品名（安卓暗潮1钻）用与
  订单同一套规格解析器拆解，系统+系列+钻级全对上才命中；系统按通配口径
  （模板写通用/双端两端都算，模板没写系统不命中——宁可不建议不给错价）；
  多条命中取最高价
- 新端点 GET /worker/consignment/price-suggestion（requireActiveWorker）
- 发布表单规格选齐后 300ms 防抖请求：同规格去重、过期响应丢弃；命中自动
  填入寄售价并提示来源与条数；卖家手改过价只提示不覆盖，换规格重新带出；
  提交成功状态复位；接口失败静默（本地没配模板保持手填，行为不变）
- 建议：本地模板没配不影响任何现有行为，生产库模板越多建议越准

后端 483（+建议价命中/不符排除/取最高/通用模板用例）/ 前端 54 测试全绿
docs/寄卖系统优化方案.md 记录批次 X
 2026-09-17 13:14:10 +08:00
yml2213 b666a9c951 fix(consignment): 拼单份额验收收官补寄卖结算钩子 + 手动匹配弹窗三处复核遗留 
- acceptWorkOrderShareAndSettle 最后一个份额把母单转 accepted 的分支，
  此前不释放发布押金也不结算供货货款（两钩子只在统一验收里）：
  现在同口径补上；供货货款传 assignedWorkerId=0（拼单母单无单一接单人，
  份额打手已各自按 share_reward 结算，不会重复付款）
- 手动匹配弹窗：race_condition/unavailable/spec_mismatch/partial_requires_confirm
  四个错误码清空已选并自动重拉列表，数据过期不再死循环撞错
- 手动匹配弹窗库存侧：keyword+pageSize100 透传后端（原来 keyword 是死参数、
  只拉 50 条），300ms 防抖后端搜索；无供货打手时禁用指派选项并在提交前
  再拦一道（原来必 400 死路）；选中订单回显 workerId/workerName
- 凭证核销反馈抽共享 utils/voucher-consume，WorkOrdersPanel 与弹窗共用，
  口径不再漂移（弹窗顺带获得"已提前核销 N 张"提示）
- docs/寄卖系统优化方案.md 记录批次 V

后端 477（+4）/ 前端 50（+1）测试全绿，typecheck / lint / format / check:sql 通过
 2026-09-17 12:45:51 +08:00
yml2213 63837e473b fix(consignment): 复核修复——占库撞 080 CHECK 必 500、指派非卖家双付货款、手动匹配权限门控 
- 占库默认 allocation_status 从自由文本改为「已安排」，不再撞 080 的
  CHECK ('待安排','已安排')；加静态守卫测试（剥注释断言枚举内默认值）
- resolveConsignmentAssignRewardFen 加 assigneeIsSupplier：指派供货卖家本人
  → 报酬=结算价（货款走报酬渠道）；指派别的打手 → 报酬保持原值（货款走
  供货货款渠道），两条渠道互斥，封住平台双付；补行为级测试 + 调用点钉住
- 手动匹配两处入口（库存面板行内按钮、拦截弹窗 footer）统一按
  consignment.fulfill 门控，编辑/作废仍为 manage，与后端权限一一对应
- docs/寄卖系统优化方案.md 记录批次 U

后端 473（+3）/ 前端 49（+1）测试全绿，typecheck / lint / format / check:sql / build 通过
 2026-09-17 12:36:12 +08:00
yml2213 f62f9b6645 fix(consignment): 售后立案回落到供货卖家，修内部现货单立不了案 
补货款时排查"只认接单人"的地方，发现同类第三处：售后立案的责任人取
work_orders.assigned_worker_id，取不到就报 worker_missing（界面 409「请指定已验收的责任
打手或拼单份额」）。内部现货履约的寄卖单没有接单人，于是这类单子连售后都立不了案；
而货款修好后钱已结算给供货卖家，担责人本来就该是他。

- 抽出共享查询 getConsignmentSupplierByWorkOrderWithClient()
  （consignment-supplier-repo.ts）：工单 material_json.consignment.inventoryId 或库存
  bound_work_order_id → 库存 → 提报单，货款结算与售后立案共用同一份口径
- 售后在找不到接单人时回落到供货卖家，并在验收快照里标记 consignmentSupplier
  与提报单号留痕
- 加测试钉住：售后必须先认寄卖关系再判定 worker_missing；取卖家的 SQL 只有一处实现

真实库验证（内部现货履约，接单人为空）：反查供货卖家 workerId=3 正确；
售后立案成功且责任人 worker_id=3。临时数据残留 0。
 2026-09-17 12:08:39 +08:00
yml2213 896194aa2b fix(consignment): 验收结算补上寄卖货款，并修指派打手线报酬 100 倍单位错 
问题：工单 #100171 验收完成时卖家钱包只有押金 -20/+20，货卖掉了但货款收益没进卖家钱包。

查证：工单报酬 reward_amount=14500 分（发单方付 ¥145），货的结算价 cost_price_fen=12400 分
（卖家应得 ¥124），而 assigned_worker_id 为空（内部现货履约）。通用结算的规则是"把工单报酬
付给接单人"，内部现货单没有接单人 → 这笔钱谁也没拿到，卖家只拿回自己的押金。

- 新增 settleConsignmentSupplierPayoutByWorkOrderWithClient()：验收完成时把货的结算价
  （cost_price_fen，缺省退回 asking_price_fen）补给供货卖家，单位与通用报酬一致（分），
  同样做售后欠款抵扣、按售后策略决定是否延迟解冻、写 reward_settlement/reward_pending_unfreeze
  流水（说明「寄卖货款结算 #单号」）
- 不重复付款：接单人就是供货卖家本人时跳过（指派打手线里货物已随工单报酬付过）
- 修 100 倍单位错：指派打手线把工单报酬改写成货的结算价时写了 (cost_price_fen/100).toFixed(2)，
  ¥124 被写成 ¥1.24；reward_amount 的单位是分（已用真实数据核对）。抽成纯函数
  resolveConsignmentAssignRewardFen() 并加测试钉住单位

真实库端到端验证：卖家钱包 ¥205.50 → ¥329.50（+¥124.00 寄卖货款结算），累计结算同步 +¥124.00；
验证脚本改动的开发库数据已还原，临时数据残留 0。
 2026-09-17 12:04:39 +08:00
yml2213 0c10f0e135 feat(consignment): 停用客服手动入库，寄卖货源只走平台提报 
背景：手动入库是唯一会造出「没有提报单的现货」的入口，这类货没有寄卖单号，
统一状态机/凭证链/搜索/卖家端单号锚定都串不起来，只能在界面回退显示内部仓库号 INV，
正是"一件货两个号"的残留。业务定调：寄卖货源只走「打手平台提报 → 客服审核入库」。

- 前端寄售仓库的「手动入库」入口整块删除（按钮 + 入库弹窗 + 提交逻辑 + 服务函数）
- 后端同时挡住，防旧页面缓存或直接调接口绕过：
  POST /worker-platform/consignment/inventories 返回 409 consignment_manual_inbound_disabled；
  死代码一并清掉（服务层原实现、仓库层 createConsignmentInventory）
- 提报审核入库路径不受影响，照旧生成内部仓库号 INV 并写 source_submission_id，
  即每件货都必然挂着寄卖单号，INV 只作为内部编号存在、界面不展示

真实库验证：接口被拒（409），且「没有提报单的现货行数」前后均为 0。
 2026-09-17 11:41:46 +08:00
yml2213 54f8a27e97 fix(consignment): 匹配弹窗改用寄卖单号，客服界面不再展示内部仓库号 
问题：内部寄售库存匹配弹窗显示的是「寄卖单号 INV26091711253394」——候选现货走的
是另一个查询 listActiveConsignmentInventoriesForMatching，它没 join 提报单，
sourceSubmissionNo 取不到，前端就回退显示内部仓库号；客服拿这个号去寄卖仓库又搜不到。

- 匹配候选查询补 LEFT JOIN consignment_submissions 带出 source_submission_no；
  该查询原本是 SELECT * 且列名无前缀，而 consignment_submissions 同样有
  status/game_name/category_id，加 join 会让条件变成 ambiguous column 直接 500，
  故列名统一加 ci. 前缀并显式列字段（加静态守卫测试钉住）
- 客服界面只展示寄卖单号：匹配弹窗候选卡片、工单寄售标识、工单详情、寄卖仓库列表与详情
  全部去掉内部仓库号；手工入库现货写「客服手工入库（无提报单号）」，
  历史老单写「老单无提报单号」，不再抛内部编号
- 内部仓库号保留：数据/接口/按它搜索都还在，撤销解绑等链路未动

真实库验证：仓库层候选查询与 checkWorkOrderInventoryMatches 都带出了寄卖单号。临时数据已清理。
 2026-09-17 11:31:01 +08:00
yml2213 ca04e09deb feat(consignment): 客服端凭证链可视化（提报凭证 + 赠送凭证） 
问题：一件寄卖有两类凭证，客服界面只看得见第一类，还是 48x48 一张缩略图，
看不出是主页还是物品；第二类（证明"这件货真送出去了"的赠送完成截图）只在工单验收界面，
客服要证明赠送是否完成得自己跨模块翻，没有任何地方把两类凭证并排呈现。

- 两类凭证分别在哪里：
  提报凭证 = 提报表 screenshots_json（卖家提报时的游戏主页截图，含物品/仓库详情）
  赠送凭证 = 绑定工单的验收资料 work_orders.acceptance_json（冷却结束后上传、客服凭此验收）
- 后端把凭证链从客服两个列表/详情接口一起下发：提报表/库存 → 结果库存 → 绑定工单，
  新增 submissionScreenshots / giftEvidenceImages / giftEvidenceNote / giftEvidenceSubmittedAt /
  giftWorkOrderNo / giftWorkOrderStatus / giftEvidenceReviewStatus（none|pending|accepted|submitted）；
  赠送凭证图从 imageUrls 与 files[].url|mediumUrl|thumbnailUrl 两处取并去重
- 提报凭证口径统一：有来源提报单用提报单主页截图，客服手工入库现货回退库存自身截图，
  前端只看 submissionScreenshots 一个字段，不会拿错
- 前端新增共享组件 ConsignmentEvidenceGallery（缩略图 + 大图预览 + 共 N 张，
  预览用 Image.PreviewGroup items，被折叠的图在大图里仍能翻看）；审核面板把「凭据截图」
  拆成「提报凭证（游戏主页截图）」与「赠送凭证」（带待验收/已验收 Tag + 关联工单 Tooltip），
  仓库面板新增「凭证」列并分组展示，两个详情弹窗同口径（含备注/提交时间/工单号/一句话说明）

真实库验证：赠送凭证解析在构造的工单验收资料上取到 3 张图（imageUrls 1 + files 2）并识别
pending_acceptance → 待客服验收；提报凭证在真实数据上取到 1 张。临时数据已清理。
 2026-09-17 11:22:59 +08:00
yml2213 44de11a3a7 feat(consignment): 一个寄卖单号锚定全流程 + 统一状态机 + 卖家侧确认加好友/提交赠送截图 
问题：一件货身上挂着三套互不相通的状态（提报单审核态、仓库库存态、工单赠送态），
my-items 同时返回两个数组、卖家端分两个列表渲染，同一件货显示两行两个号；
且卖家端只映射了前两套状态，"已出库"之后流程就断了，卖家不知道该干什么。

- 提报单号 SUB… 作为唯一「寄卖单号」从发布锚定到结算（零迁移）；
  listWorkerConsignments 改成一件货一条记录，库存/工单信息挂上去，
  客服手工入库的现货（无提报单）才回退用库存号当锚点
- 新增 domain/consignment-item-stage.ts：把三套底层状态推导成卖家看得懂的一个阶段
  （待审核/已通过待匹配/已匹配-待加好友/冷却中/待赠送/已赠送待审核/已完成/驳回/作废/取消）
  + 一句"下一步做什么" + 能力位（谁能确认加好友、谁该传截图），列表筛选与 KPI 也改由它驱动
- 卖家侧新增动作（以前只有 publish + my-items，卖家只能干看）：
  POST /worker/consignment/items/:submissionId/{confirm-friend,gift-evidence}
  POST /worker/consignment/inventories/:inventoryId/{confirm-friend,gift-evidence}（手工入库现货）
  复用既有工单链路 confirmWorkOrderFriendAdded / submitWorkerOrderAcceptance，
  只加归属校验（不是本人履约的订单 403），顺带白拿"冷却没结束不许提交凭证""必须带图"
- 客服端用同一个号：库存列表/详情补 sourceSubmissionNo（LEFT JOIN 提报单），
  履约/指派写进工单的寄售信息也带上；关键字搜索支持按寄卖单号搜（计数 SQL 同步补 join）

真实库端到端验证：确认加好友 → gift_phase=friend_countdown / friend_added_at 落库 /
gift_available_at 正好 +72h；冷却期内提交截图被拒（work_order_gift_cooldown_active）；
越权操作被拒（consignment_item_not_found）；按寄卖单号搜索命中正确。临时数据已清理。
 2026-09-17 10:57:57 +08:00
yml2213 d158cc91bc feat(consignment): 确认加好友后现货作废不回池，撤销履约押金可选并结算打手押金 
现货口径（严）：已确认加好友 = 买家好友已加上、货随时可能送出去，回池会被下一个工单
再次占用（等于二次出货）。收口在 releaseConsignmentInventoryBindingForWorkOrderWithClient：
解绑前读工单 acceptance_mode/friend_added_at，命中则 archived + allow_matching=FALSE + 留痕，
否则仍回池。所有解绑路径自动继承，发单系统接口未动。

撤销寄售履约（寄卖专属入口）支持两笔押金各自可选，默认按规则自动：
- 打手履约押金：auto / refund / forfeit
- 卖家发布押金：auto / keep_frozen / forfeit
策略抽成 domain/consignment-deposit-policy.ts 纯函数；覆盖时原因照旧必填，选项与金额写进
工单事件便于对账。

顺带修掉两个 bug：
1. 撤销寄售履约从不结算打手履约押金——只清 assigned_worker_id、只处理卖家押金，
   worker_deposit 单撤销后打手押金永久冻结。现按选项结算（退还/没收）。
2. detachConsignmentMaterialFromWorkOrderWithClient 里 $1 既作 $1::text（detachedAt）
   又赋值给 updated_at，Postgres 整体推断成 text → 42804。凡解绑现货摘寄售标记的路径
   （取消指派/撤单/退单/售后/撤销履约/人工回库）在真实库上必然 500，假 client 单测抓不到。
   已显式 ::timestamptz，并补类级静态护栏扫同类写法。

验证：真实库（全回滚）——已确认加好友解绑 → archived/allow_matching=false；
未确认 → 仍 in_stock；打手押金冻结 3000 → 退还 3000（重复结算 0）→ 再冻 2500 → 没收 2500
（可用余额不变、冻结归零、流水 deposit_deduction）。后端 432 例（新增 5 例）全绿。
 2026-09-17 10:21:38 +08:00
yml2213 a47c243421 feat(consignment): 确认加好友后卖家发布押金不退，并封住二次冻结的 500 
需求：确认加好友之后押金不退回，卖家的押金也不退回。

- 新增 forfeitConsignmentPublishDepositBySubmissionWithClient /
  ...ByWorkOrderWithClient：release 的镜像——可用余额不动、只扣冻结额，写一条负数
  deposit_deduction 流水并带上工单号与 giftDepositForfeited 标记。
  台账 outstanding 会把 deposit_deduction 计入已核销，因此之后同一提报单的
  release 与重新冻结都拿不到钱，天然幂等、退不回去。
- 挂载点：取消指派/撤单/退单/售后回退等 6 处「押金不退」判定点，以及「撤销寄售履约」的
  作废与回库分支（后者原来会把押金留着或直接退还卖家）。
- 修掉一个会 500 的边角：押金已退还/已没收时 ensureConsignmentPublishDepositFrozenBySubmissionWithClient
  会去插第二条 deposit_freeze 流水，撞上"每个提报单只允许一条冻结流水"的唯一索引
  （没收后现货回库、再被匹配后撤销/退回复库即可触发）。现显式抛
  consignment_deposit_already_settled，两个服务层都映射成 409 文案。

验证：真实库（回滚）验证没收全链路——冻结 2000 → 工单侧没收 2000 → 可用余额不变、
冻结额归零、流水为 deposit_deduction(-2000, 关联工单)；没收后 release 恒为 0。
后端 420 例（417 通过，新增 5 例）全绿。
 2026-09-16 21:27:47 +08:00
yml2213 d6f6219fe9 feat(consignment): 内部现货履约改为停在「待加好友」，由客服确认后进赠送冷却 
需求：发布匹配成功后订单要停在待加好友，客服线下通知加好友、手动确认后才进赠送冷却。

- 新增 parkWorkOrderWaitingFriendAddWithClient：占库落地时把工单停在
  acceptance_mode=friend_gift + gift_phase=material_required 的「待加好友」阶段，
  friend_added_at / gift_available_at / deadline_at 都留空（没有打手在跑，不该背时限），
  并把商品规则里的冷却时长落到工单上（两者都为 0 时补默认 72 小时，
  否则客服确认后会得到 0 秒冷却而立刻可赠送）。
- 履约服务不再传 forceFriendGift（该开关会直接把 friend_added_at 写成当前时间、
  跳过客服确认）；同步删除这个已无调用方的开关，冷却起始事件里的
  skippedWorkerMaterial 改为按是否内部现货履约判断。
- 前端：内部现货单在该阶段显示「待加好友」（原为「待打手提交资料」），
  确认按钮统一为「确认加好友」，确认弹窗补上"先用库存账号加好友、通知进展记备注"的引导。
- 后台备注增加快捷项「已通知加好友」，一键追加「[已通知加好友] 操作人 时间」。
- 阶段文案抽到 utils/gift-phase.ts 以便单测覆盖这条口径。

验证：真实库跑通全链路（停阶段 → 确认加好友进冷却 → 重复确认被拒 → 事件流正确，临时单已清理）；
后端 415 例（412 通过，新增 3 例）、前端 25 例（新增 4 例）全绿。
 2026-09-16 21:02:50 +08:00
yml2213 5d11bf2012 fix(consignment): 补齐指派补偿与规格复检，封闭寄卖资金/货物不一致窗口 
- 指派失败改为完整补偿：取消指派（解冻打手押金 + 工单退回大厅 + 解绑现货）→ 兜底释放占用 →
  摘除工单寄售标记。此前只把现货放回在库池，一旦"指派已提交、写 material 失败"，工单会停在
  in_progress + 押金冻结却不带寄售记录，现货还回到可匹配池，同一件货会被第二张单占用。
- 电子凭证核销失败写 consignment_fulfill_voucher_consume_failed 事件，前端按 voucherConsume.ok
  弹警告并提示人工核销，不再无条件报成功（核销走快手外部接口，无法与数据库事务合并回滚）。
- 匹配规格改为 match/mismatch/unknown 三态，钻级兜底由 || 1 改 || 0：订单规格信息不全一律不进
  "精确匹配"，降级 partial 并在原因里列出缺失字段，消除"任意现货都 100 分精确匹配"的错发根因。
- 履约与指派在占库前做服务端规格复检：冲突 409 consignment_spec_mismatch；非 exact 必须显式
  传 allowPartial（前端在部分匹配候选上先危险确认），高配充低配保留但不可误触。
- 人工解绑守卫由"状态黑名单"收窄为只拦交付中三态（与撤销白名单对齐），修复
  "工单未开始 + 现货仍绑定"没有任何人工出口的问题。
- 新增 detachConsignmentMaterialFromWorkOrderWithClient，解绑回库/人工退回复库/作废同步摘掉
  工单寄售标记，消除"已回库却仍显示寄卖履约"的陈旧痕迹。
- 回归测试新增 8 例（后端 410 例 / 407 通过），附迁移 079 上库前检查脚本。
 2026-09-16 20:12:14 +08:00
yml2213 632dddc4c3 fix(consignment): 下线 H5 收集链接渠道并封闭寄卖履约状态机 
下线定向收集链接（H5 填报）整条线，提报统一走接单平台打手端：
- 删除前端 ConsignmentCollectPage、consignment-public 服务与 /consignment-collect/:token 路由
- 删除后端公开路由 routes/consignment.ts、consignment-public-service 与管理端 /consignment/links 三接口
- 迁移 079 删表 consignment_collect_links、删列 consignment_submissions.link_id，
  source_type 的 collection_link 归并为 worker_portal 并替换 CHECK

修复手工入库/编辑的凭据与截图静默丢失：后端统一按 credentialsJson ?? credentials、
screenshotsJson ?? screenshots 读取（入库/编辑/审核入库三个入口）。

按"已验收一律禁止撤销"封闭状态机：
- 撤销寄售履约加状态白名单（in_progress|pending_acceptance|problem）+ 事务内 FOR UPDATE
  锁单 + UPDATE 带 status 条件（0 行 409）+ 原因必填 + 清空指派/时限/验收草稿痕迹
- 库存改状态一律带条件：撤销要求 bound_work_order_id 命中本工单；作废/回库要求未被
  进行中工单占用（被挡时提示具体工单号）；079 加部分唯一索引并清理历史重复绑定
- 工单终止统一解绑回库：打手撤单/取消指派/退回大厅/撤单/打手退单申请/超时处置接入
  releaseConsignmentInventoryBindingForWorkOrderWithClient（售后不改工单状态，无需接入）
- 回库路径保留运营的 allow_matching 开关设置（不再强制开启），前端文案同步更正

顺带修掉资金与归属的同源缺陷：
- 押金归属与重冻金额改取不可变的冻结核销行，审核改派不再"退给错人/向错人扣款"
- 新增 assigned_worker_id 拆开"卖家"与"被指派履约人"，占库不再覆盖卖家
- PUT /inventories/:id 禁止直接改 status；发布接口补 requireActiveWorker
- 押金冻结/释放后补推钱包实时事件；迁移 079 给发布冻结加台账幂等唯一索引

验证：后端 401 测试/398 通过/3 skip（新增 5 例回归），前端 16 通过；
两侧 typecheck、lint:check、format:check 与 check:sql、build 全绿。
迁移 079 未经真实数据库执行（本环境无 Postgres），上库前请先 dry-run。
 2026-09-16 20:05:49 +08:00
yml2213 e828e677a5 fix(consignment): 打通寄卖权限鉴权、指派占库竞态与撤销守卫 
- 后台权限白名单补齐 consignment.view/manage/review/fulfill，
  避免在「角色权限」页保存任意角色时静默清除寄卖权限
- 寄卖后台 19 个接口由 requireAdminRoles 改为 requireAdminPermission，
  使 view/manage/review/fulfill 四个权限真正生效
- 指派打手履约改为先原子占库（WHERE status = 'in_stock'），
  失败自动回滚库存，消除并发下同一件现货被两张工单同时认领
- 撤销寄售履约拒绝押金履约模式（worker_deposit），
  避免打手押金不释放造成资金挂账；前端同步隐藏该入口
- 撤销回库不再强制覆盖 allow_matching，保留运营手动关闭的匹配开关
- 新增 4 个回归测试：权限白名单与迁移一致性、占库/回滚条件、撤销守卫
 2026-09-16 11:38:08 +08:00
yml2213andCursor 6b9407967b style: 修复赠送冷静期 cooldownMinutes prefer-const 
Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-15 20:04:03 +08:00
yml2213andCursor fd1eb5815b feat(consignment): 内部现货占库进入赠送冷静期并闭环发布押金 
打手发布冻结履约押金，驳回/作废退还，验收释放；内部匹配履约立刻占用库存并跳过打手资料进入冷静期，撤销回库时补冻押金。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-15 20:03:11 +08:00
yml2213andCursor 4a6215e816 feat(consignment): 苏尔南寄卖接入打手端押金履约 
打手可直接提报寄卖，关联 worker 与履约押金后指派交枪；后台去掉旧收集链接管理，提报审核与库存/工单流程对齐接单平台。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-15 16:00:33 +08:00
yml2213 7672360875 Merge branch 'main' into dev 2026-09-15 14:17:36 +08:00
yml2213andCursor acfe7fd07e style: 修复订单与调度相关 Prettier 格式 
Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-15 13:48:43 +08:00
yml2213andCursor 40c51e1d8e fix(admin): 订单列表默认近7天并按支付时间筛选 
避免无日期过滤时展示全库，关键词搜索不受日期限制；SSE 插入裁剪并尊重筛选，新单入库优先使用平台支付时间。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-15 13:41:29 +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 5cbb977b96 fix(pdd): 匹配诊断对齐 out_sku_sn，并加速拼多多订单号搜索 
匹配测试/结构化规则补读商家编码，诊断日志标出缺失字段；订单/任务/工单关键词支持带连字符的 PDD order_sn 走索引快路径。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-15 10:45:53 +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 1aa6dba931 feat(consignment): 新增和平精英寄卖库存管理、定向收集审核与工单智能匹配履约 2026-09-14 11:39:15 +08:00
yml2213andCursor a49db84771 fix(worker-platform): 修复售后欠款抵扣导致验收失败，并支持余额偿还 
有待还欠款时结算写入 settled_at 发生 timestamptz/text 类型错误会整单 500；顺带支持充值/解冻自动偿还与后台手动偿还。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-13 20:44:35 +08:00
yml2213 aba508f4f6 feat(worker-platform): 分类标识改为系统自动生成并在前端UI隐藏 2026-09-13 14:25:51 +08:00
yml2213 061a5d897f feat(worker-platform): add worker withdrawal blacklist and admin actions 2026-09-13 11:32:42 +08:00
yml2213 9fcc4ef99d feat(product-rules): 接单模板列表支持二级目录层级联动筛选 2026-09-13 10:51:36 +08:00
yml2213 d1e06f362e feat(category): 接单平台支持二级分类目录与接单大厅联动展示及限额优化 2026-09-12 18:45:56 +08:00
yml2213 fea82bff36 style(backend): 格式化代码并修复floating-promises以通过pre-push检查 2026-09-12 17:46:47 +08:00
yml2213 71912ef5d0 feat(worker-platform): 接单平台全面改用内部统一工单号，隐藏第三方平台单号防泄漏 
1. 新增业务工单单号生成器 generateWorkOrderNo()，生成 WO+年月日+时分+随机数的统一内部单号（如 WO26091216358821）；
2. 接单平台抢单大厅、订单列表、详情抽屉、模态弹窗及售后全面切换为展示 workOrderNo，彻底屏蔽拼多多/快手等第三方平台来源标识；
3. 打手资金明细补充关联内部工单号 relatedWorkOrderNo，避免打手在账单中识别原平台；
4. 管理后台工单面板升级为双单号清晰展示（高亮内部工单号 + 辅助可复制平台单号），兼顾打手对单与官方平台售后溯源。
 2026-09-12 16:44:59 +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 1217da7393 feat(worker-platform): 支持后台配置匹配日志保留上限与天数并提供一键清理历史多余记录 
1. 扩展商品匹配配置支持 maxMatchLogs (条数上限) 与 matchLogRetentionDays (保留天数)；
2. 新增分批物理清理逻辑 pruneWorkProductMatchLogs，通过索引高效分批删除超出限制的记录；
3. 集成定时任务数据保留清理 data-retention-job，并在保存配置与写入时自动滚动清理；
4. 匹配诊断日志面板新增可视化保留策略设置栏，支持管理员自定义上限、一键保存并提供一键清理超出记录按钮。
 2026-09-12 16:01:26 +08:00
yml2213 1b6e117c7f perf(order-repo): 优化后台订单关键词搜索，提取关键 JSON 字段并保留现有 GIN 索引命中 2026-09-10 10:13:00 +08:00
yml2213 4544622cb3 优化后台订单列表展示并支持商品标题与SKU规格 2026-09-10 09:39:19 +08:00
yml2213 fe2a28454d 增加打手列表筛选汇总 2026-09-06 12:55:58 +08:00
yml2213 4c6c53d818 优化后台任务与订单按订单号搜索性能 2026-09-04 21:58:44 +08:00
yml2213 84a8f138d4 优化接单平台工单查询性能 2026-09-04 21:22:35 +08:00
yml2213 625df52992 新增财务申请时间类型筛选 2026-09-02 14:32:26 +08:00