dachui/order_site
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
1,095 Commits 3 Branches 0 Tags
42961dd789fc52ca8a3f3ff3d753e23477347944
Commit Graph
1095 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
yml2213 0df5c9f34e feat(worker-platform): 抢单大厅首页新增联系客服胶囊入口并抽象通用客服弹窗组件 
1. 抽离打手端通用联系客服弹窗组件 WorkerContactModal，统一维护微信二维码、打手账号/状态/余额回显、一键复制及沟通提示；
2. 抢单大厅移动端顶部状态栏（余额上限右侧首屏黄金位）新增精致微动效【联系客服】胶囊按钮，大幅缩短找客服沟通链路；
3. 抢单大厅桌面端头部操作栏同步补齐【联系客服】按钮，并在个人中心账号弹窗中统一复用 WorkerContactModal；
4. 适配移动端与超窄屏自适应响应式样式，完成前端59项测试与全量打包构建验证。
 2026-09-21 12:37:38 +08:00
yml2213 a4f6f5ed9b style(worker-portal): 优化打手端我要寄卖页面顶部卡片布局，轻量化重构首屏体验 
1. 移除第 4 个占位无意义的「发布寄卖 苏尔南」卡片，核心指标精准收敛为待审核、履约中、已完成 3 大状态；
2. 新增 worker-consignment-kpi-grid 紧凑统计栏，移动端改为横向 3 列等宽平铺，高度由 320px+ 骤降至 52px，竖向空间节省超 80%；
3. 剔除卡片内无实际价值的长句副说明文案，改为上行轻量状态标签 + 下行醒目数字的微排版，支持点击秒切记录过滤；
4. 彻底解决移动端首屏被巨幅卡片占满导致表单下沉的问题，首屏直接呈现履约押金提示与规格选择，提升打手发布效率；
5. 前端 59 个自动化测试全绿，全套 check 与 build 100% 通过。
 2026-09-21 12:31:03 +08:00
yml2213andCursor 577e0eec02 fix(consignment): 内部现货履约文案对齐待加好友，并移除已废弃的指派打手路径 
Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-21 12:04:30 +08:00
yml2213 29589bb9af feat(worker-platform): 接单工单表格「打手」列支持展示寄售供货打手与现货资料 
1. 新增 resolveConsignmentWorkerDisplay 工具函数，自动解析工单寄售现货与资料字段（供货打手、游戏角色昵称、游戏ID及联系方式）；
2. 优化 renderWorkOrderWorkers 渲染逻辑：当工单为内部寄售现货履约时，打手列带「供货打手」或「内部现货」专属角标，主标题展示打手名/角色名，副标题拼接游戏ID与联系方式，解决原先显示为破折号 - 的问题；
3. 新增 consignment-worker-display 单元测试，更新寄卖库存优化现状与进度追踪文档，前端 57 个测试全绿并通过类型检查。
 2026-09-21 11:40:25 +08:00
yml2213 c80bd0e337 fix(worker-platform): 修复寄售匹配工单详情中卖家上架截图丢失问题，并收敛手动匹配为内部现货直接履约 
1. 修复文件归一化器 normalizeUploadedFiles 遇到纯字符串 URL 数组被误过滤为空的问题，自动提取 objectKey 并构造规范 UploadedFile 结构；
2. 优化工单展示映射器 resolveWorkOrderEffectiveBoosterMaterial：当工单资料中截图为空时，自动回退并加载寄售卖家上架/主页截图；
3. 前端管理后台详情抽屉与打手端详情抽屉支持读取 detailOrder.gift.boosterMaterial.screenshots 与 consignmentInfo.screenshots 降级兜底渲染；
4. 手动匹配弹窗与发布拦截弹窗全面收敛为单一标准的【内部现货直接履约】，废除旧版指派打手带来的重复扣押金与二次填资料问题；
5. 新增 consignment-booster-material 单元测试，更新寄卖库存优化现状与进度追踪文档，前后端全套测试通过。
 2026-09-21 11:35:38 +08:00
yml2213andCursor 040b3db84c fix(finance): 移除资金审核取消按钮，避免提现冻结资金未退回 
Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-20 21:59:29 +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 e5cc7cadef style: 格式化后端工单查询与展示映射模块代码风格 2026-09-19 14:41:16 +08:00
yml2213 f08a221e15 feat(worker-platform): 接单平台工单详情抽屉支持卖家与买家资料一键复制与单项复制 
1. 寄售赠送进度卡片右上角新增【一键复制卖家资料】按钮，一键聚合复制卖家角色昵称、游戏ID、区服、系统、联系方式（微信/QQ/手机）、提报/仓库单号及备注；
2. 资料信息卡片右上角新增【一键复制买家资料】按钮，一键复制买家提交的全部表单字段；
3. 卖家资料与买家资料的各项字段值（角色名、数字ID、区服、系统、联系方式、单号等）右侧均补充内联一键复制小图标，支持快捷单项提取。
 2026-09-19 14:39:43 +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 13a9028c66 feat(worker-platform): 发布寄卖与我的寄卖界面支持停留状态与筛选持久化记忆 
1. 在 WorkerConsignmentPage 中通过 localStorage 与 URL 查询参数实时双向同步 activeTab 与 recordFilter；
2. 打手在切换发布寄卖/我的寄卖或筛选状态后，刷新页面或切换路由返回时自动恢复上次停留界面；
3. 提交寄卖成功后自动切换并记住跳转到我的寄卖-待审核列表。
 2026-09-19 14:23:51 +08:00
yml2213 d40b5a4c1c feat(worker-platform): 优化打手我的寄卖卡片资料展示，前置展示打手自身上架账号资料 
1. 后端 consignment-worker-service 在我的寄卖列表中解析并返回打手上架时填写的 sellerInfo（角色名、数字ID、区服系统、微信号/QQ、寄卖留言等）；
2. 前端新增 ConsignmentSellerInfoBlock 卖家资料区块，提供角色名/ID高亮与一键复制功能；
3. 寄卖卡片布局升级为前置展示【我的寄卖账号资料】、后置展示【买家加好友资料】，多号上架时号主与买家清晰对应，彻底杜绝登错号加错人。
 2026-09-19 14:19:35 +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 c0d00d28ce fix(admin-orders): 修复实时 SSE 订单推送未按时间倒序排列导致历史单跳到第 1 行的闪烁问题 
1. 在 AdminLayout 的 patchAdminOrderListEnvelope 中接入 sortAdminOrdersDesc 排序引擎，严格按 paidAt / createdAt 倒序及 orderId 倒序排列；
2. 修复后台同步历史订单（如 15/16 号）时，SSE 事件盲目将其插入第一页顶部并在手动刷新后消失的跳跃与闪烁现象；
3. 新订单按时间自然沉降到正确的页码位置，只有属于当前页时间范围的新订单才会展示在第一页顶部。
 2026-09-19 11:49:48 +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 9a342e7ea6 feat(pdd-extension): 插件升级至 v1.2.0，增加防休眠心跳、会话主动续期与超时弹窗秒级拦截 
1. 新增 content.js 页面级保活引擎，自动注入拼多多商家后台 (mms.pinduoduo.com)；
2. 主动防休眠与静默续期：每 2 分钟向 MMS 接口发送轻量只读心跳并派发微动作，主动刷新服务端 PASS_ID 有效期，从根本上阻止空闲弹窗生成；
3. 超时弹窗秒级自动拦截：使用 MutationObserver 实时监听 DOM，毫秒级捕获「当前页面停留时间过长」弹窗并自动点击「刷新」，彻底解决页面挂死导致 Cookie 会话过期被踢出账号的问题；
4. 后台长效平滑刷新：后台标签页静置超 25 分钟自动执行无感安全重载，保障 CSRF Token 与会话 24 小时鲜活；
5. 日志链路打通：将页面防休眠、弹窗拦截与周期刷新事件接入扩展日志控制台。
 2026-09-19 11:06:32 +08:00
yml2213 67d68d37f6 feat(worker-platform): 对齐生产环境分类树并增强寄卖匹配多品类硬隔离门禁 
1. 接入生产分类树体系：将 ItemCategoryType 对齐生产 work_categories 真实分类（苏尔南手枪、苏尔南钻石、特种兵密钥、地铁逃生、大转盘车皮、蛋仔派对、王者荣耀、第五人格、人气礼物等）；
2. 强化跨游戏与跨子类隔离：精准拆分地铁逃生下的苏尔南钻石与苏尔南手枪，杜绝钻石充值单误匹配手枪现货；
3. 严格品类硬隔离门禁：对齐 matchPeacekeeperOrderWithInventory 与 describeConsignmentSpecDifferences，品类冲突时彻底拒绝匹配并在非精确列表中置为 conflict 沉底；
4. 补充全品类匹配与隔离单元测试，覆盖手枪、密钥、车皮、钻石、跨游戏等测试用例。
 2026-09-19 10:46:18 +08:00
yml2213 8631100d07 style: 统一代码格式化与代码规范 2026-09-19 10:41:15 +08:00
yml2213 c62c8c2cad feat(worker-platform): 增加寄卖匹配品类隔离门禁，杜绝手枪跨品类误匹配密钥礼盒 
1. 新增 detectItemCategory 与 formatItemCategoryLabel 品类主体识别器（覆盖苏尔南手枪/枪皮、特种兵密钥、爆破型肩炮、专属礼盒、改名卡、点券等类目）；
2. 寄卖匹配比对中引入强品类隔离门禁，在宽松模式下亦严禁跨品类误判为非精确匹配；
3. describeConsignmentSpecDifferences 补充品类级差异冲突说明，非同品类订单自动沉底；
4. 补充专项单测并保证全量测试与构建通过。
 2026-09-19 10:40:02 +08:00
yml2213 a5727554a4 feat(worker-platform): 彻底去除非平台内部现货履约，寄卖匹配全面收敛为接单平台指派打手 
1. 手动指定现货弹窗移除 deliveryKind 冗余单选框，统一收敛为一键指派供货打手履约；
2. 匹配确认后自动冻结打手履约押金、启动交付倒计时与履约时效监控，消除脱管盲区；
3. 订单发布前置拦截弹窗移除内部代交付入口，统一为走接单平台指派；
4. 未关联供货打手的现货进行明确阻断与告警提示，避免无监管指派；
5. 同步更新前端静态单测并保证全量测试与构建通过。
 2026-09-19 10:28:23 +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 f816f57eb0 fix(worker-platform): 补齐寄售凭证类型导入与平台单号测试格式化 
1. 修复 consignment-worker-service.ts 缺少 WorkOrderRow 类型导入的问题；
2. 规范化 platform-order-id.test.ts 与 worker-platform-service.test.ts 代码风格。
 2026-09-18 19:40:29 +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 68cd309bdd refactor(consignment): 清理寄卖库存详情与编辑中的上号凭据旧字段 
1. 物品详情弹窗中移除登录方式、账号、密码、上号说明等旧上号字段，保留履约信息与备注；
2. 编辑物品弹窗中移除上号凭据信息卡片，聚焦现货规格、成本、供货打手与备注。
 2026-09-18 18:45:59 +08:00
yml2213 ace4791005 feat(consignment): 寄卖物品已验收后隐藏退单回库按钮并拦截退库 
1. 寄卖库存管理面板中，已验收通过的现货记录不再展示「退单回库」按钮；
2. 后端 returnAdminConsignmentInventory 接口增加校验，若关联工单已验收结算则拒绝退库，后续问题引导走售后流程。
 2026-09-18 18:43:22 +08:00
yml2213 771deb221e style(worker-consignment): 优化寄卖卡片截图展示为紧凑单行并排布局 
1. 将提报商品截图与赠送凭证截图重构为同一行紧凑胶囊栏，减少上下两行占用空间；
2. 分别保留商品截图与赠送凭证的张数、缩略图与大图预览画廊，视觉更精致。
 2026-09-18 18:38:43 +08:00
yml2213 c38f6dfbfd feat(worker-consignment): 寄卖卡片同时展示提报商品截图与已提交赠送截图 
1. 寄卖记录卡片同时保留提报商品截图展示区域与赠送凭证截图展示区域；
2. 提报商品截图与赠送凭证截图带清晰分类标题与张数统计，方便卖家完整核对。
 2026-09-18 18:36:51 +08:00
yml2213 c17b8a78d5 fix(worker-consignment): 修复卖家提交赠送截图后在接单平台无法回显的问题 
1. 后端 listWorkerConsignments 接口从关联工单验收资料中提取 giftEvidenceImages、giftEvidenceNote、giftEvidenceSubmittedAt 并在打手端寄卖列表中下发；
2. 接单平台「我的寄卖」卡片新增已提交赠送凭证展示模块，支持展示缩略图、张数统计、大图预览及赠送备注；
3. 优化提报单与库存、工单的 SQL 关联兼容双向绑定，确保后台与前台均能稳定查到赠送凭证。
 2026-09-18 18:35:15 +08:00
yml2213 8228776b8c fix(files): 修复 304 缓存未销毁流导致的 S3 连接池泄漏与图片挂起卡死 2026-09-17 21:03:20 +08:00
yml2213 c5d1e2c375 feat(consignment): 寄售匹配成功后向卖家端与客服后台透出买家加好友资料 2026-09-17 20:46:45 +08:00
yml2213 eff45bb9a8 fix(consignment): 优化撤销寄售履约弹窗（无接单打手时隐藏打手履约押金，正名供货打手发布押金） 2026-09-17 20:10:00 +08:00
yml2213 9180b5f61c feat(consignment): 高规格（超配钻级/璀璨）寄卖建议价自动按当前最高档位报价 2026-09-17 19:23:01 +08:00
yml2213 1526907005 feat(consignment): 建议价精准匹配璀璨数 + 限制璀璨不超过钻石数量 
- 修复价格匹配：parseSpecsFromText 支持「璀」字缩写（1璀/2璀/3璀）与「无璀/0璀」，
  避免生产规则被误判为 0 璀；suggestConsignmentPriceFromRules 增加 brillianceCount
  精准对齐匹配，未配对应模板则返回空，解决同钻级多条规则全中并取最高价的问题
- 透传参数：路由与打手端服务均增加 brillianceCount 传递
- 限制璀璨不超过钻级：
  - 前端选项动态禁用：大于当前钻级的璀璨芯片置灰
  - 钻级调小自动收敛：若原选璀璨大于新钻级，自动 clamp 至新钻级
  - 默认值与联动：璀璨数默认 initialValue=0，queryKey 纳入璀璨，切换即刻带出对应建议价
  - 前后端双重校验：前端表单 Validator 校验 + 后端提报硬拦截（brilliance_exceeds_diamond）
- 后端 487 / 前端 54 测试全绿，docs/寄卖系统优化方案.md 记录批次 Z
 2026-09-17 19:14:04 +08:00
yml2213 ccb5b6f4d6 docs: 清理过时文档（以代码为准） 
删除（整篇已被代码淘汰 / 重复副本 / 与仓库无关）：
- cloudflared_tunnel.txt：全仓无 cloudflared 配置，个人终端记录，无任何引用
- 履约配置/工程债-lewan拆分与短链.md：文中 services/kuaishou-cloud 与 kuaishou-cloud-executor 已删除
- 履约配置/快手Cloud领取mock.md：mock:claim / mock:feifei 与 dev-mock 卡片已移除（只剩 mock:open91）
- 行业电子凭证/解决方案/技术方案/1.基础技术.md（+ 其孤立 image.png）：0.基础技术.md 的 75 行截断副本
- 寄卖库存功能设计与实施方案.md：手工入库已 409 停用、收集链接表已随 079 删除、统计看板未实现
- 服务器图片迁移到阿里云OSS.md：MinIO→OSS 迁移已完成（生产 STORAGE_MODE=oss）
- pgBackRest备份方案分析.md：全仓无 pgBackRest 落地痕迹，文档自述暂缓实施
- finance-implementation-plan.md：财务模块已落地（072 迁移 / RBAC / 页面接口），已实现部分与代码重复
  （未落地的二期三期路线图可从本提交的历史版本取回）

改写为与代码一致（已下线通道不再当作现行能力）：
- 履约配置/多发货平台与电子凭证整体链路.md：kuaishou-cloud / kuaishou-feifei 标注为已下线 legacy stub，
  现行自动通道 affiliate-dash、人工 manual_dispatch；核销时机与券表按实现校正
- 履约配置/{UID领取与旧单兼容, open91请求, TypeScript类型收紧}.md：lewan/feifei/cloudtentacles 表述改为
  现行 affiliate-dash 链路；normalize 具名类型 KuaishouCloudFlow/FeifeiFlow → AffiliateDashFlow
-  affiliate_dash_发货平台/affiliate-dash对接.md：§13/§14/§19/§21/§24/§25 的已删文件与已下线通道引用校正，
  §21/§22 加「当时快照 / 落地后现状」横幅，回调去重表按 013_affiliate_dash_webhook_events.sql 改写
- 91卡券/{3.异步卡密下单, 5.当前项目对接配置, 6.开发设计}.md：删掉不存在的后台入口、
  cloudtentacles/kuaishou_ct_assisted 依赖、cardsEncoding 与 .js 代码落点校正
- 行业电子凭证/技术方案.md：checklist 指向不存在的 测试用例.md → gen-test-cases.ts + 5.测试指南.md
- 履约配置/cloudtentacles发货平台.md：补「本仓库未接入该通道」说明（保持外部参考）
- 部署启动与数据库重建.md：补齐生产必需变量 APP_DOMAIN / CORS_ALLOWED_ORIGINS / STORAGE_MODE / STORAGE_OSS_*

其它：
- README.md：迁移序号范围 002~009 → 002~080
- 寄卖系统迁移079上库前检查.sql：第 2 段注释按批次 Y 的自动去重更新；新增 2.1「重复退款风险」只读排查
  （已在一次性 PostgreSQL 16 上跑通 001→080 迁移：整份脚本 exit=0，脏数据下 2/2.1 均按预期报警）
- 寄卖系统优化方案.md：删掉链路图里已下线的「客服手工录入」，去掉指向已删设计稿的引用
 2026-09-17 16:57:27 +08:00
yml2213 617794f2cf docs: 寄卖系统优化方案记录批次 Y（079 迁移去重修复） 2026-09-17 13:35:41 +08:00
yml2213 2e8c9715b6 fix(migration): 079 建冻结幂等索引前先去重历史重复冻结并退还多冻押金 
生产首跑 079 在 uniq_worker_wallet_ledgers_consignment_publish_freeze
索引上 23505：历史存在同提报单两条 consignment_publish 冻结流水
（如提报单 5），正是该索引要防的二次冻结缺陷的脏数据产物。

与 079 处理重复绑定工单同套路——先清数据再加约束：
- 每组（worker+提报单）保留最早一条冻结流水，多余行仅改 payload
  标记 consignment_publish_superseded（移出押金口径与索引范围，原行留审计）
- 多冻的钱退还钱包：退额 = LEAST(多冻总额, 冻结池实有)，绝不无中生有；
  写 deposit_release 修正流水（kind=consignment_publish_dedup_refund）
- 同一打手多条多余流水先按钱包聚合再退，避免 UPDATE..FROM 漏退
- 再建幂等索引

已在一次性 Postgres 完整复现生产路径验证：078+脏数据 → 079/080 迁移
成功、钱包退回多冻 ¥20、索引生效拦截第三次冻结
 2026-09-17 13:34:39 +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 4e076ed628 style(worker): 寄卖规格 chips 只有一个选项时四角统一圆角 
苏尔南区服现在只有「互通」一个选项，chips 的 :first-child/::last-child
圆角规则同时命中、last-child 在后覆盖成"左方右圆"；补 :only-child
规则让唯一选项四个角都是 8px 圆角，与多选项时的观感一致
 2026-09-17 13:04:27 +08:00
yml2213 f8101c1730 feat(consignment): 规格口径定案——互通通配 + 后台全量/发布端按物品展示 
业务定案：
- 操作后台全量：系统 苹果/安卓/通用，区服 微信区/QQ区/互通；提报审核与
  库存编辑的系统/区服从自由文本改为受控下拉（单一来源 utils/consignment-spec.ts）
- 打手端发布按物品类型展示：苏尔南系统二选一（必须区分端），区服唯一
  「互通」选项且默认选中；后续其他品类在共享常量按品类加条目
- 匹配引擎通配符对称化：区服通配=互通（通用/全区/不限归一化为别名），
  系统通配=通用（双端/全端同理）；订单侧写通配同样放行，只增不减匹配面；
  差异描述不把通配对当冲突
- 提报白名单校验（API 层）：系统只收 苹果/安卓，区服只收 微信/QQ/互通，
  旧页面缓存或直调接口绕不过
- 物品名拼接：区服为互通时不拼入（对买家无信息量），前后端同口径

后端 481（+互通双向匹配/通配不算差异/真冲突仍排除/白名单校验）、
前端 54（+选项口径/表单引用/默认值）测试全绿；typecheck/lint/format/check:sql 通过
docs/寄卖系统优化方案.md 记录批次 W
 2026-09-17 13:01:59 +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 0476339ec4 fix(consignment): 手动匹配订单按钮点了不弹窗（弹窗挂错了位置） 
用户反馈：在库待匹配列表点「手动匹配订单」没有反应。

根因：上一批把手动匹配弹窗挂到了「编辑寄售物品」弹窗**内部**，外层弹窗未打开时
该组件根本没被挂载，点击只改状态、界面无变化。

- 弹窗移到面板顶层（与其它弹窗同级），点击即弹
- 新增静态守卫测试：断言手动匹配弹窗前面不能有未闭合的 Modal（即不能嵌在别的弹窗里）、
  按钮必须真的 setState、open 由该状态驱动；已验证该守卫能拦下错误写法
- 顺带补入口缺口：订单侧原先只在"检测到系统候选"的提醒弹窗里给入口，订单没有任何候选时
  反而进不去手动匹配 —— 工单行内新增常驻「手动匹配现货」（仅待指派/待补资料，
  与后端前置校验同口径）
- 已暂停匹配的现货点按钮会直接 409，改为按钮禁用并提示先打开「允许匹配」开关
- destroyOnClose → antd 6 的 destroyOnHidden（前者已废弃）

验证：前端 typecheck/lint/format/48 例测试/build 全过。
 2026-09-17 12:27:58 +08:00
yml2213 a7a55d6c16 feat(consignment): 客服手动指定现货匹配的界面入口 
后端批次已提供判定/差异/强制留痕与双向读取接口，这里补界面，让客服真的能用上。

- 新增共享弹窗 ConsignmentManualMatchModal：订单侧（匹配弹窗「手动指定现货匹配」）与
  库存侧（寄售仓库行内「手动匹配订单」）共用同一套交互与落地逻辑，避免两套 UI 漂移
- 交互：搜索 → 选中（精确/非精确/规格冲突三档标签 + 字段级差异说明）→ 选交付方式
  （内部现货履约 / 指派供货打手）→ 非精确需勾选确认、冲突需勾选「确认规格不一致」并必填原因
  → 落地；并在落地前提示"现货立刻被占用、点错需撤销寄售履约"
- 判定规则收敛成纯函数 consignment-manual-match.ts（需不需要确认/填原因、能否提交、
  关键词过滤、标签文案）并加 4 例单测
- 服务与类型补齐：fetchWorkOrderConsignmentMatchOptions / fetchInventoryMatchableOrders，
  fulfill/assign 入参增加 allowSpecMismatch 与 matchNote
- 凭证核销失败的提示沿用既有规则（核销失败不能报成功）

验证：前端 typecheck/lint/format/44 例测试/build 全过；两个新接口未登录访问均 401
（路由已挂载、权限位生效）。
 2026-09-17 12:23:30 +08:00
yml2213 94328ac643 feat(consignment): 后端支持"手动指定现货"匹配（含规格冲突强制匹配留痕） 
需求：客服在后台能人工指定现货与订单匹配，而不是只能用系统算出的候选。

- 新增纯函数 listConsignmentMatchOptions()/classifyConsignmentMatch()：把某订单的**全部**
  在库现货列出来并逐件判定 exact/partial/conflict，conflict 时给出字段级差异
  （describeConsignmentSpecDifferences，例如「系统：订单「苹果」/ 现货「安卓」」）
- 新增 describeWorkOrderSpecConflicts()：强制匹配时把差异写进工单 material 与事件留痕
- fulfill/assign 两条落地链路支持 allowSpecMismatch（规格真冲突显式放行）+ matchNote
  （强制匹配必填原因，否则 400 consignment_match_note_required），
  material 与工单事件都记录 manualMatch/matchType/matchNote
- 新增两个只读接口：订单侧 GET /consignment/matches/:workOrderId/options（全部在库现货+判定），
  库存侧 GET /consignment/inventories/:id/match-orders（该现货可匹配的待指派/待补资料订单+判定）
- 抽取 classifyConsignmentMatch 让正反两个方向共用同一套匹配口径，避免"界面说能选、接口却拒绝"

真实库验证：订单要苹果微信暗潮2钻、现货为安卓QQ苍龙4钻时正确判定 conflict 并列出 4 项差异；
不填原因强制匹配被拒（consignment_match_note_required）；不强制则被规格复检拒绝
（consignment_spec_mismatch）；填原因强制匹配成功且工单事件与 material 都有留痕。
 2026-09-17 12:20:23 +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 40882aeebb fix(consignment): 确认加好友与上传赠送截图恢复为卖家操作，客服兜底 
问题：卖家「我的寄卖」里"已匹配-待加好友"的货点不了确认加好友，提示还写着"等待客服确认加好友"。

原因：批次 I 把能力位绑在"订单接单人 = 当前卖家"（selfFulfilling）上，而内部现货履约的订单
根本没有接单打手（assigned_worker_id 为空），于是状态机关掉按钮、后端归属校验还会 403。

业务定调：卖家可以确认加好友，冷却到期后也能自己上传赠送成功截图，客服只是兜底。

- 能力位改成按阶段给：material_submitted 可确认；内部现货履约在 material_required 也可确认
  （与客服侧一致）；冷却结束可提交赠送截图；提示改成卖家视角
- 后端归属只认"这张提报单就是当前卖家的"（别人的单仍 404），删除"订单接单人必须是卖家"的 403
- 卖家提交凭证走 asConsignmentSupplier 选项：跳过接单人校验（归属由寄卖单保证），
  冷却是否结束、必须带图等校验全部保留
- 客服侧按钮不变，谁先点谁生效，后点者拿到明确 409

真实库端到端验证：卖家列表按钮=true → 确认加好友 gift_phase=friend_countdown(+72h) →
冷却中被拒 work_order_gift_cooldown_active → 冷却到期后卖家上传赠送截图成功（工单转 pending_acceptance）。
 2026-09-17 11:57:33 +08:00
yml2213 0fd09976a5 fix(files): 去掉文件链接的签名与有效期，修客服端凭证裂图 
问题：寄卖凭证的图片地址是带签名的临时链接（15 分钟有效），而入库时会把当时的链接
原样存进 screenshots_json；工单验收那条线出参时会用 refreshStoredFileUrl() 重签，
寄卖这条线（提报凭证/赠送凭证/卖家列表）漏了这一步，于是入库 15 分钟后链接必然失效，
客服看到裂图。图片本身没丢，是取的时候没重签。

业务定调：签名这套意义不大，直接去掉。

- buildFileUrl() 只产出不带签名、不带有效期的普通链接（对象 key 带随机段，不可枚举），
  删除签名生成/校验与 15 分钟 TTL 常量，文件读取路由不再校验签名
- refreshStoredFileUrl() 语义改为"归一化"：把历史存的签名链接洗成普通链接，老数据不用改也能看
- 寄卖出参统一归一化：提报凭证、赠送凭证（imageUrls + files[]）、库存截图、卖家列表截图

真实库验证：库里早在 2026-09-15 就过期的老链接现在返回 HTTP 200（image/webp，52632 字节），
改造前是 403；客服接口下发地址已无签名；不存在的 key 仍 404。

取舍：文件路由原本靠签名把关，去掉后知道链接即可看图（key 含 24 位随机段，实际不可枚举）。
如需收紧可给该路由加后台登录校验。
 2026-09-17 11:52:40 +08:00
yml2213 e731348bb0 refactor(consignment): 删掉按库存号操作寄卖的卖家入口 
手动入库停用后，"没有提报单的现货"已不可能再产生，批次 I 为兜这类货加的两个
按库存号入口（/worker/consignment/inventories/:inventoryId/...）成了纯负担。

- 删除两个按库存号的路由/服务函数、前端两个请求函数与页面里的锚点分派逻辑，
  卖家动作只按提报单号（寄卖单号）定位
- 卖家列表里"没有提报单"的兜底行不再暴露内部仓库号（标题改「客服手工入库」），
  且一律不给操作能力位，不给用户一个点下去必然失败的按钮
- 加静态守卫测试钉住以上两点，防止以后又长出按库存号的入口

真实库验证：卖家列表三件货都带寄卖单号与 submissionId，没有提报单的现货 0 件。
 2026-09-17 11:45:50 +08:00