dachui/order_site
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
895 Commits 3 Branches 0 Tags
0c10f0e13591575ec20e83258c63e6e00402a127
Commit Graph
178 Commits
Author SHA1 Message Date
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 47e09d72ce fix(consignment): 内部寄售匹配弹窗防点错 
问题：弹窗里「走接单平台指派打手（冻结押金交付）」与「内部现货履约」两个按钮上下紧挨、
样式相近，而且只有"部分匹配"才弹确认——精确匹配时两个按钮点下去都立刻执行，
点错就得走「撤销寄售履约」才能退回来。

- 两个动作一律二次确认（不再只有部分匹配才确认），确认框写明：寄卖单号（可复制）、
  动作（给谁接单/是否冻结押金）、结果（立刻占用现货、其它订单不能再匹配、
  内部履约还会跳过「待打手提交资料」直接进冷却）、以及退回要走撤销寄售履约；
  部分匹配额外红字提示"不是精确匹配、无法自动回退"并把确认按钮降为 danger
- 按钮区改成独立的「选择履约方式」分区小卡片：两个按钮各占一行 block 铺满
  （点击目标更大、不再小按钮挨着）、间距 14px、各加图标（打手 TeamOutlined /
  库存 PushpinOutlined），每个按钮下方一句后果说明
 2026-09-17 11:33:23 +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 99752dce9e fix(consignment): 修掉发布时乱弹内部库存提醒，并把弹窗赏金换算成元 
乱弹窗根因：matchPeacekeeperOrderWithInventory 精确匹配判定失败后无条件 fall through 到
部分匹配；而系统/区服/系列/钻级缺失时 compareSpec 返回 unknown（不是 mismatch）会被放行，
于是任何只写了游戏名的订单都命中仓库里全部在库货，表现为"随便发布点什么都会弹一下"。

严格模式（自动提醒）现在要求：① 系统/区服/系列都能确认一致；② 存在正信号（库存配置更高，
或订单压根没提钻级）。"订单没写规格"不再算命中。

同时给 matchPeacekeeperOrderWithInventory / findMatchingPeacekeeperInventories 增加
allowUnspecifiedSpecs 选项：人工履约的服务端复检（运营已人工选定现货）走宽松模式，
标题没写全规格不硬拦、真冲突仍拦，避免收紧自动提醒时把人工履约一起挡掉。

赏金显示：弹窗用 rewardAmount（单位分）直接 toFixed，把 ¥40 显示成 ¥4000；
同文件其他 30 余处均为 /100，仅此处漏了。弹窗内收购成本/履约押金本来就已 /100，核对无误。

验证：用截图里的现货（苹果QQ区怒嚎3钻2璀璨）对照 6 种订单——
"怒嚎"、"苏尔南" 从命中变为不命中；"苹果QQ区怒嚎1钻" 仍按高配充低配提醒；
"5钻"（低配充高配）、"安卓微信区怒嚎1钻"（系统/区服不符）不命中。
后端 435 例（新增 3 例、改写 3 例）全绿。
 2026-09-17 10:30:17 +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 563e548b2e feat(consignment): 补齐寄卖前端权限门控，收口调拨状态与运营体验 
权限门控（P1-8 剩余）：
- 新增 resolveAdminPermission(sessionPermissions, code)：会话接口的最新权限列表优先，
  接口异常才回退登录时的本地快照；空数组也判无权限，避免"刚被收回权限仍能点"。
- 寄售仓库面板：consignment.manage 控制手动入库/编辑/作废/退单回库/匹配开关（无权限时开关禁用）。
- 寄卖提报面板：consignment.review 控制审核入库/驳回。
- 接单平台页：无 consignment.view 不渲染两个寄卖 tab，并把 URL/localStorage 的旧选择拉回工单页。

数据约束（P2-19 剩余）：
- 迁移 080：allocation_status 历史非法值归位「待安排」（备注留痕）后加 CHECK（待安排/已安排），
  并顺手修正 077 遗留的"收集链接/玩家提交"权限描述文案。
- 编辑接口拒绝直接改 allocationStatus（400 consignment_allocation_status_update_forbidden）。

运营体验：
- 两个面板补 isError 错误态与重试；审核通过/驳回加 confirmLoading 与提交中守卫（防双提交）。
- 待审徽标改用后端真实总数（原来只统计当前页）；编辑弹窗押金不再兜底 ¥100（会误写押金）。
- 履约拦截弹窗冷静期文案不再硬编码"3 天"，改为按商品规则设定。
- 核实并撤回"倒计时时区偏移"误报：deadlineAt 为带 Z 的 ISO，前端无偏移问题。

验证：后端 412 例（409 通过）、前端 21 例（新增 5 例权限解析）全绿，
typecheck / lint / format / check:sql / build 通过；迁移 001→080 在全新空库跑通并在 dev 库应用。
 2026-09-16 20:39:52 +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 7672360875 Merge branch 'main' into dev 2026-09-15 14:17:36 +08:00
yml2213andCursor 4a3b4ec14d refactor(fulfillment): 固化 91 中文名→英文 SKU 权威映射表 
91 继续用中文编码；解析优先查内置常量表，配置仅作临时覆盖，Admin 改为展示权威表。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-14 20:33:42 +08:00
yml2213 1aa6dba931 feat(consignment): 新增和平精英寄卖库存管理、定向收集审核与工单智能匹配履约 2026-09-14 11:39:15 +08:00
yml2213 84a8f138d4 优化接单平台工单查询性能 2026-09-04 21:22:35 +08:00
yml2213 bf167d98ed 新增财务角色与财务报表并完善后台权限 2026-09-02 13:58:03 +08:00
yml2213 737c957bb3 chore(deploy): 资源默认值适配 4 核 8G 共用服务器 
- postgres mem_limit 1.5g/shared_buffers 384MB/effective_cache_size
  4GB/work_mem 16MB/maintenance_work_mem 256MB
- backend mem_limit 768m、cpus 1.5;web 保持不变
- 生产与开发编排、env 模板、运维文档同步更新
 2026-08-30 14:07:39 +08:00
yml2213 6dcdec43f1 chore(deploy): 数据库与各服务增加资源限制和优雅关闭保护 
- postgres 增加 mem_limit/cpus/shm_size/stop_grace_period 与 PG
  性能参数(shared_buffers 等,env 可覆盖);backend/web 增加
  内存/CPU 限额与更长的优雅关闭宽限(生产与开发编排同步)
- ubuntu-deploy.sh 增加部署前磁盘空间预检,防止备份或迁移
  中途磁盘写满
- .env.server.example 补充资源变量;文档补充容器资源限制说明
 2026-08-30 13:59:19 +08:00
yml2213 fb0e9c8f9c 增加备份文档 2026-08-23 15:24:37 +08:00
yml2213 d56189fe59 完善数据库备份恢复链路 2026-08-23 14:39:30 +08:00
yml2213 9080476dd6 生产编排移除内置MinIO图片存储全面改走阿里云OSS 2026-08-23 13:38:32 +08:00
yml2213 6d7f9b5f3f 准备迁移1 2026-08-23 12:54:38 +08:00
yml2213 1b8e02dd17 增加数据库慢查询观测与索引防线并收窄打手拼单分页查询 2026-08-22 18:40:11 +08:00
yml2213 bc2909d6f2 打手端迁移至独立子域名 2026-08-16 16:08:38 +08:00
yml2213 49705f2774 优化 affiliate-dash 商户单号 2026-08-11 09:48:05 +08:00
yml2213 4e9c416235 affiliate-dash 领取界面优化(合并多次迭代为一次提交) 
- 第 2 步绑定页:移除金额/单号/商品信息区,移除标题上方 affiliate-dash 标签
- 二维码区参考旧设计:左右竖排红字 Q区用Q扫/V区用V扫,去浅蓝背景,放大至 220px
- 第 4 步结果页:废弃 canvas 生成发货成功图,改用旧版结果卡片(绿勾+兑换成功+信息网格+商品明细)
- 开发 Mock:新增 affiliate-dash 领取五步 mock(uid/bind/submitted/completed/failed,不调真实平台)
 2026-08-05 19:39:15 +08:00
yml2213 316ee6d135 履约配置页 affiliate-dash 覆盖收尾:preferredMatchEnabled 开关补入平台配置 UI 
- 分析结论:履约路由面板已含 affiliate_dash(开关/优先级/规则),职责划分成立
- 缺口修复:指定匹配优先开关此前无 UI 入口,现平台配置 affiliate-dash tab 增加 Switch
- 后端 effective 透出 preferredMatchEnabled;前端类型/panel 补齐
- 前后端 typecheck 通过,224 测试全绿
 2026-08-05 17:52:14 +08:00
yml2213 5f5a1a8bcf 重构:affiliate-dash 平台配置从履约配置页移至平台配置页 
- AdminPlatformShopsPage 新增 affiliateDash tab + AffiliateDashPlatformPanel(密钥/钱包/商品/映射/测试)
- AdminPlatformFulfillmentPage 移除 affiliate-dash tab 与组件
- 后端与 API 路径不变(本就挂 /platform-config),纯前端 UI 归位
- 前端 tsc -b 通过
 2026-08-05 17:45:44 +08:00
yml2213 0f81380d9c 新增透传:91 编码与 affiliate_dash sku 一致时自动命中 
- resolveAffiliateDashSkuByProductNo 改 async,匹配两级:①指定映射(skuMapping 归一命中) ②透传(productNo == affiliate_dash 商品 sku)
- 商品列表内存缓存 5 分钟,拉取失败返回上次缓存/空集合,匹配 miss 走其他通道不阻塞下单
- 两层命中均触发指定匹配最高优先(preferredExecutorKey)
- 测试 +3(224 全绿);线上验证 suit_alan_walker/suit_cloud_bear 透传命中,乱码回退
 2026-08-05 17:40:13 +08:00
yml2213 769d41655a 优化履约匹配:指定匹配(91中文名→sku映射)最高优先 + 映射键归一化 
- 91 商品编码全部为中文名(幸运币90个等),运营按中文名→affiliate_dash sku 配置显式映射
- resolveFulfillmentRoute 新增 preferredExecutorKey:映射命中强制优先(规则之前),停用/不可用回退原逻辑
- matchAffiliateDashSku 归一化:NFKC 全角→半角、去空白、小写,先精确再遍历
- preferredMatchEnabled 配置(默认 true,可一键回退,不耽误现有 cloud/feifei 生产)
- 测试 +9(221 全绿);行为验证:映射命中/全角/空格命中,未映射回退
 2026-08-05 16:44:37 +08:00
yml2213 5f5506bb19 docs: 履约匹配逻辑深度分析(§21 痛点 P1-P8 + 优化建议分档) 
- 匹配链路全貌:91 item → 三路匹配 → 路由(规则/优先级/manual_review) → planner 动态 profile
- 8 个痛点:P1 精确映射排在名字模糊匹配之后(可信度倒挂)、P2 productNo 未拆 ---- 后缀、P3 映射键无归一化、P4 缺名字兜底、P5 余额不参与路由、P6 双轨配置冲突、P7 重复计算、P8 命名语义误导
- 优化建议分档:快赢档 P1-P3 / 中档 P4 / 后档 P5-P8;按用户指示先分析不改代码
 2026-08-05 16:14:35 +08:00
yml2213 7fc3d60588 新增 affiliate_dash 回调路由与幂等去重(阶段 5) 
- POST /api/v1/open/affiliate-dash:验签 → 查任务(404 重试) → webhook_events 幂等闸门 → 状态同步
- migration 013:webhook_events(provider+event_id 唯一)
- task-repo findAffiliateDashTaskByOrder(仿 feifei 同构 SQL)
- notify-service:去重闸门在找到任务之后,任务未匹配不被 eventId 永久拦截
- typecheck + 212 测试通过;前置错误分支脚本验证通过
 2026-08-05 16:07:33 +08:00
yml2213 00d490a2cd 优化 affiliate_dash 核销时机:建单成功即核销(参考 feifei 给用户链接即核销) 
- prepareAffiliateDashTask 建单成功(91 卡信息到手、链接可发放)立即核销行业电子凭证
- 核销失败不阻塞下单与链接发放(consumeStatus=failed, delivered 回调兜底补核销)
- sync delivered 分支 alreadyConsumed 短路,避免重复核销
- typecheck + 212 测试通过
 2026-08-05 16:02:44 +08:00
yml2213 5ef1ed6018 新增 affiliate_dash 统一领取页流程(阶段 4) 
- 后端:claim 详情分流 affiliate_dash 分支 + 详情轮询刷新 bind-result
- 输 UID 触发 bind(拿 bindUuid/二维码, task→waiting_binding)
- 新增 POST /claim/:token/affiliate-dash/submit(submit→redeeming + 事件)
- 前端:ClaimAffiliateDashSteps(二维码/绑定状态/mismatch警告/提交发货)
- claim-snapshot/claim-poll 按 flowType 分流(step2 绑定中/step3 已绑定待提交/step4 结果)
- 前后端 typecheck + 后端 212 测试通过
 2026-08-05 15:56:51 +08:00
yml2213 3284fed7a1 新增 affiliate_dash 履约配置与商品映射(阶段 3) 
- bootstrap CORE_PROFILES + routing ROUTABLE/DEFAULT_PRIORITY 接入 affiliate_dash
- planner 上下文 affiliateDash 块 + resolveDynamicAffiliateDashProfile
- product-resolution: 91 productNo→sku 映射匹配(skuMapping) + snapshot.affiliateDash
- prepare 前余额预检(getAffiliateDashWallet)
- AFFILIATE_DASH_SKU_MAPPING_JSON env 注入
- admin 后端接口(GET/POST 配置、match、products、wallet)+ 前端 Tabs 面板
- 联调:模拟 91 进单命中 affiliate_dash 路由, 未命中回退;前后端 typecheck + 212 测试通过
 2026-08-05 15:08:41 +08:00
yml2213 867ffd2f3c 新增 affiliate_dash 履约 executor(阶段 2) 
- executor 常量/守卫 + affiliate-dash-executor(preparePaidTask/resolveDeliveryLink)
- 履约业务实现:prepareAffiliateDashTask(幂等建单, client_order_no=task_no, data 透传 91单号/game_account)
  + syncAffiliateDashTaskStatus(状态合并: delivering→redeeming / delivered→核销→redeemed /
  ship_failed→retry_pending / cancelled→closed)
- registry 注册 + 测试(212 全绿)
- 真实建单联调通过(线上 skin.khhao.com,幂等不重复扣款)
- 修复 POST /orders 响应 data.order 映射层级
 2026-08-05 14:56:36 +08:00
yml2213 a6ba5f1c7f 新增 affiliate_dash 发货平台客户端与签名(阶段 1) 
- 平台配置接入:runtime-config/types/defaults/env-overrides/app-config-keys 增加 affiliateDash
- affiliate-dash 平台客户端:请求签名(§3.1 app_key+body_sha256)、回调验签(§3.2 timingSafeEqual)、
  http-client 封装(超时/错误归一/全链路日志)、订单/交付/钱包/商品接口封装
- 单测 12/12 + 全量 211 通过,真实联调拉取线上商品 33 个验证签名链路
- 新增 affiliate_dash 对接文档 v2(含契约验证结论与深度分析)
 2026-08-05 14:51:40 +08:00
yml2213 9053a06481 有效期改成 30 天 2026-07-27 13:08:48 +08:00
yml2213 792680bd19 重构 lewan 履约：拆分发货模块并统一 registry 入口 
将 task-finalization 拆为 dispatch/stock/return/redeem/confirm 等用例，
claim 与 admin 经 executor registry 调用；admin 退号仅清理虚拟号不核销。
 2026-07-10 22:23:26 +08:00
yml2213 042574dea3 继续收紧 TypeScript：ClaimIdentity 契约与 flow 出口类型 
- 新增 types/claim-identity，统一 ClaimIdentity / Payload / AdminSummary
- 导出 KuaishouCloudFlow、KuaishouFeifeiFlow 作为 normalize 出口
- 生产路径 JsonObject 统一从 types/json 导入，去掉 rebind as any
- 前后端 claimIdentity 类型字段对齐
 2026-07-10 15:56:25 +08:00
yml2213 8bcd9bbd81 收紧后端 TypeScript：统一 Json 类型与 TaskContext 契约 
关闭 allowJs；集中 JsonObject 定义并替换分散 any 别名；parseTaskContext 返回 TaskContext；任务详情 API 标注 AdminTaskDetailView；测试减少 as any。
 2026-07-10 15:52:05 +08:00
yml2213 d6b0e45c7b 偿还 lewan 工程债：模块拆分、默认角色降级与短链收口 
将 kuaishou-cloud 大入口拆为 prepare/rebind/probe/refresh 等模块；默认角色仅作诊断；补充兑换状态单测；短链明确只读兼容历史链接。
 2026-07-10 14:01:29 +08:00
yml2213 8de56b0354 优化 UID 履约闸门、运营可见性与一键兑换 
lewan 发货强制 expectedUid 并取消无 UID 旧路径回落；任务详情展示 UID 匹配态；领取页匹配后可一键兑换；补充 identity 单测并收口短链说明。
 2026-07-10 13:51:02 +08:00
yml2213 3c0d1f108c 新增开发 Mock 后台菜单与造单能力 
非生产环境在后台提供 lewan/feifei 领取造单与 91 查单模拟，CLI 复用同一服务，避免依赖真实平台联调。
 2026-07-10 13:35:42 +08:00
yml2213 1155b3c608 文档对齐 React 技术栈，并支持渐进式数据库迁移 
将 README 与部署文档从仅 init 改为 001 基线 + 增量迁移约定，并补充 create/status 脚手架与序号校验。
 2026-07-10 12:36:36 +08:00
yml2213 ca5433ada4 优化客服权限 2026-07-10 12:00:23 +08:00
yml2213 c61078d3f6 新增快手电子凭证后台工具 2026-07-09 18:39:34 +08:00
yml2213 102330d7af 增加文档 2026-07-08 12:33:15 +08:00
yml2213 010ca4e249 增加文档与图片 2026-07-07 23:22:56 +08:00
yml2213 dbcb5a4979 重命名前端目录 2026-07-07 19:55:18 +08:00