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 |
|
yml2213
|
72e1141c8a
|
feat(finance): 补齐自动发货与接单平台成本和对账
自动发货:价格导入支持 --effective-from,把首次基线版本回填到历史起点;41,676 个订单项全部归一并生成采购成本快照,缺失 0。\n\n接单平台:新增按工单 product_rule_id 回填商品的接口与按钮,长尾项按 provider+shop_id+sku_code+normalized_sku_name 补建 wo: 商品和 sku_code_name 渠道映射;118,053 个订单项全部归一。\n\n成本:已验收工单按 reward_amount 写 actual;未验收但已确定报酬的工单写 estimated,验收后升级。全量 95,870 actual + 21,217 estimated,actual 与 reward 0 差异。\n\n剩余 966 条取消/零报酬工单保留在成本异常队列,不自动记 0;人工块未改动。\n\n实测自动发货与接单平台未归一收入均为 0;整体未归一 79.67% 降至 57.54%,全部来自人工块。
|
2026-10-22 18:59:53 +08:00 |
|
yml2213
|
54d2eb2f59
|
feat(finance): 自动发货订单项按上游 SKU 直接归一
自动发货只有 affiliate-dash 单一上游渠道,订单项直接按 fulfillment_tasks.context_json.skuCode 归一为 aff:<skuCode>,不写 channel_product_mappings。\n\n新增 /cost-center/affiliate-products/backfill:按 order_item_id 取最新任务 SKU 回填 canonical_product_id,只更新有变化的订单项,并自动重算受影响日期的销售事实;返回 updatedCount/skippedCount/remainingCount。\n\n自动发货 SKU 列表改为实时统计履约任务数与最近履约时间,不读会被价格导入覆盖的 attributes_json。\n\n本地实测 41,676 个订单项全部归一,自动发货未归一收入 5,089,712.26 元降至 0;整体未归一占比 79.67% 降至 60.47%。
|
2026-10-22 18:41:31 +08:00 |
|
yml2213
|
0889235870
|
feat(finance): 完成成本快照运行层、销售事实与人工支出登记
迁移 108-111:快照业务时间与预估转实际、销售事实表、系统成本项、公司人工支出登记。接单平台按工单实际 reward 入账;人工支出支持登记/审批/驳回/报销并写 actual 快照。新增销售毛利页、人工支出页与订单入口。
|
2026-10-22 16:41:03 +08:00 |
|
yml2213
|
39cf14ed7a
|
merge: 同步 main 最新到 dev(接单平台店铺筛选)
|
2026-10-22 15:30:38 +08:00 |
|
zhaoxing
|
067d54fdd8
|
接单平台:新增店铺筛选条件
|
2026-10-22 14:45:40 +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
|
3e73289e31
|
merge: 合并 main 到 feat/cost-center-wip(同步抖音券、设备认证与图标等最新改动)
|
2026-10-22 12:40:18 +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
|
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
|
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
|
9ce29964c7
|
style(frontend): 格式化前端代码并修复 eslint 异步操作未标记告警
- 统一 prettier 代码风格;
- 为 AdminTaskDetailPage 与 AdminTasksPage 中未捕获的 Promise 添加 void 标记;
- 验证方式:npm --prefix apps/frontend run check 全流程通过。
|
2026-10-11 15:20:54 +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
|
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
|
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
|
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 |
|
yml2213
|
eacca11768
|
feat(claim-skin): 买家皮肤领取页(路径式 /claim/<token>)
买家从卡券/订单消息里的链接打开,看到物品图片与信息,填游戏账号即可领取。
- **路径式无 `#`**:新增独立 BrowserRouter 分支(照 `/redeem` 的做法),
`isClaimSkinPath` 只认 `/claim/<token>` 两段精确匹配;
打手领取页仍是主站 HashRouter 的 `#/claim/:token`(其 pathname 为 `/`),两者互不影响
- **物品卡片**:商品图(映射不到或加载失败都降级为占位块,不出现破图)、
内部 SKU、数量 ×N、订单号、引流标题(灰色副信息)
- **领取表单**:按接口下发的 `claimFields` 动态渲染(游戏账号/角色ID),
提交前二次确认让买家核对账号
- **状态**:待领取展示表单;已领取展示成功态(优先于 tokenStatus);
token 失效/过期/关闭/已用分别给中文提示与联系客服引导
- 纯函数抽到 `utils/claim-skin.ts` 并补 20 个单测(路由判定、状态映射、字段校验、格式化)
|
2026-10-09 15:06:56 +08:00 |
|
yml2213
|
8c33ff62ec
|
feat(redeem): 固定兑换链接 /redeem(输入订单号 → 状态分流 → 兑换)
- 路径式入口 `https://<域名>/redeem`(不带 #):主站是 HashRouter,
故在 App.tsx 里早于 isWorkerSite() 插入独立 BrowserRouter 分支,
主站与打手站路由均不受影响;Caddy 已有 try_files 兜底,无需改部署
- 页面按 7 种状态渲染:not_found / unpaid / cancelled / refunded /
pending_certificate / redeemable / verified
- not_found 保留用户输入的订单号,不清空
- pending_certificate 只给显式「刷新」,不做自动轮询(公开限流接口,避免空转)
- verified 只展示后端已掩码的券码,绝不渲染明文 certNo
- confirm 不假设成功:一律按返回的 status 重渲染
- 纯函数抽到 utils/redeem.ts(无 React/antd、无 @ 别名),可直接跑单测
|
2026-10-09 12:01:35 +08:00 |
|
yml2213
|
080480f03b
|
feat(admin): 后台新增「抖音码速达」配置面板
- 新增 Tab:/admin/platform-shops?tab=douyinMashida
- 面板字段:enabled / baseUrl / uid / secret / certLink / afterVerifyLink /
afterVerifyMessage / messageType / timeoutMs / handledTopics(tags)
- 密钥脱敏:出参 secret 永远为空,输入框未编辑时对外 value 恒为 '',
掩码不会污染后端「空串=保留原值」语义
- 顶部展示 ready 状态,未就绪时用 Alert 列出缺哪几项;
始终展示平台侧要配的推送地址(可复制)
- baseUrl 命中本地地址时提示「当前指向本地网关桩,不会请求真实码速达」
- 把 AdminPlatformShopsPage 内联的 SecretFieldControl 抽成共享组件
(函数体与原实现逐字节一致,8 处既有调用点参数不变)
|
2026-10-09 12:01:29 +08:00 |
|
yml2213
|
78c676d2b9
|
feat(worker-risk): 风控后台页面(可调阈值/实时状态/事件留痕/人工封禁解封),并修复解封后仍被 403 的 bug
## 修复的 bug(生产已发生)
风控三级封号把 tracker.banned 置为 true 后,banned 检查发生在鉴权之前,
而它只存在于进程内存。后台把账号改回 active 时数据库变了、内存没变,
于是账号在库里已经正常、请求却永远 403,只能等容器重启才恢复。
修法两道:
- **数据库是唯一事实来源**:banned 改为带 30 秒 TTL 的缓存,到点回查
worker_users.status;已解封(或账号已删)则清除标记并放行。
对被判 banned 的 key 最多每 30 秒查一次,即便对方仍以 65 QPS 刷也只是
每 30 秒一次查询。查询失败时**保守维持封禁**,不因数据库抖动放行刷子。
- **后台改状态时主动释放**:review 只允许设 active/rejected/disabled/pending_review
(没有 frozen),所以走到那里就意味着不再由风控冻结,直接释放内存状态。
顺带修掉一个连带缺陷:解封时只清了 violationCount,没清滑动窗口计数,
账号刚恢复就会被上一轮残留的 windowCount 立刻限流、并在 60 秒内二次封禁。
现在整轮窗口状态一并清零。
## 新增后台页面
接单平台 → 风控(/admin/worker-platform?tab=risk-control),三块:
- 阈值配置:6 个阈值可视化编辑,落 app_config_entries,保存即热生效,无需重启
- 当前实时风控:进程内存状态(已封禁/惩罚中/仅记录),支持人工解封、封禁、仅释放内存状态
- 风控事件留痕:worker_risk_events 分页查询,可按类型/IP 筛选
## 关键取舍
只记**显著事件**(二级惩罚、三级封号、人工处置),不记每一次被拒请求。
被刷时实测 45~65 QPS,按请求写库正是最初要解决的问题。实时计数仍走进程内存。
事件写入为 fire-and-forget 并吞异常,留痕失败绝不影响大厅请求。
## 验证
- 新增 6 个用例覆盖解封立即生效、对账自愈、TTL 不重复查库、对账失败保守维持、阈值可配置
- 迁移 089 已在临时库实测:表结构/4 索引/CHECK 约束/外键均正确,非法 event_type 被拒
- 后端 557 测试 554 通过 0 失败;前后端 typecheck/lint/format/build 全绿
|
2026-10-02 17:05:25 +08:00 |
|
yml2213
|
1636616ec1
|
feat(worker-platform): 寄卖价格改由接单模板只读定价,我的寄卖支持服务端搜索与分页
1. 寄售价不再由卖家填写:打手端改为只读展示模板价(与履约押金同款只读框),服务端在发布时按同一套规则复算金额,保证展示口径与落库口径一致,直连接口也无法随意定价;
2. 模板缺档按「最接近的已配置档位」报价、距离相同取更低档:后台只配了 1/3/7 钻时,号主出 2 钻报 1 钻价、出 6 钻报 7 钻价,不再因为中间档没配价而拿不到价格;
3. 我的寄卖列表把分组、关键字、翻页全部下沉到 SQL:新增 listWorkerConsignmentPage 用 UNION ALL 合成「提报单行 + 无提报单库存兜底行」,CASE 推导 待审核/履约中/已完成 分组,返回当前分组 total 与三个分组的角标计数;
4. 关键字覆盖寄卖单号、规格名、系统/区服/系列/钻级、卖家角色名与数字 ID、联系方式、买家昵称与游戏 ID(读取 work_orders.material_json.collect.fields 的多种历史键名);
5. 前端搜索框 300ms 防抖后才请求服务端、换分组或换关键字自动回到第 1 页、列表底部增加分页器,并移除原来固定 pageSize 200 的隐形截断;
6. 新增仓库层与匹配层单测,其中包含 SQL 分组 CASE 与 domain/consignment-item-stage.ts 的 group 映射交叉断言,防止两处状态机漂移;后端 516 项、前端 66 项测试全部通过。
|
2026-10-01 11:07:28 +08:00 |
|
 yml2213andCursor
|
9298b31b9b
|
feat(worker-platform): 增加寄卖白名单总开关,关闭后全员可发布
资金配置与打手列表可一键切换白名单模式;发布校验、打手端入口按总开关放行。同时收紧未开通判定、关权限确认和开通弹窗文案。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-09-21 14:23:00 +08:00 |
|
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 |
|
 yml2213andCursor
|
040b3db84c
|
fix(finance): 移除资金审核取消按钮,避免提现冻结资金未退回
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-09-20 21:59:29 +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
|
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
|
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
|
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
|
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
|
e731348bb0
|
refactor(consignment): 删掉按库存号操作寄卖的卖家入口
手动入库停用后,"没有提报单的现货"已不可能再产生,批次 I 为兜这类货加的两个
按库存号入口(/worker/consignment/inventories/:inventoryId/...)成了纯负担。
- 删除两个按库存号的路由/服务函数、前端两个请求函数与页面里的锚点分派逻辑,
卖家动作只按提报单号(寄卖单号)定位
- 卖家列表里"没有提报单"的兜底行不再暴露内部仓库号(标题改「客服手工入库」),
且一律不给操作能力位,不给用户一个点下去必然失败的按钮
- 加静态守卫测试钉住以上两点,防止以后又长出按库存号的入口
真实库验证:卖家列表三件货都带寄卖单号与 submissionId,没有提报单的现货 0 件。
|
2026-09-17 11:45:50 +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
|
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
|
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 |
|
 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
|
03dffcfbb8
|
fix(pdd): 彻底修复拼多多模板匹配被来源/平台/sku_code 误拦截
PDD 复用快手模板时,残留的 91kaquan/kuaishou 与误填 sku_code 会让 out_sku_sn 对上模板名仍未命中;改为 OR 匹配并放行常见残留,同时在匹配测试返回拒绝原因诊断。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-09-15 11:28:40 +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
|
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
|
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
|
85272cde46
|
fix(worker-hall): 优化抢单大厅两级分类联动体验并支持分类图片浏览器长效缓存
|
2026-09-13 11:02:10 +08:00 |
|