13 Commits

Author	SHA1	Message	Date
break	70e680eb0a	feat(手机号资产关联): AUG26-009 手机号—资产关联、十项上限与后台解绑 ... - 新增成对迁移 000223（tb_phone_asset_association，含有效关系部分唯一索引与 down 守卫）与 000224（解绑导入任务表），不回填历史 - H5：need_bind_phone 三支判定（开关关闭完全短路）；已有主号幂等建联；十项上限按手机号 advisory 串行化（含换绑到全新号的并发场景）；换绑原子迁移与冲突整单回滚；不写遗留列 - 后台：关联列表、单项/批量解绑、CSV 导入解绑（B1–B16），超管/平台 gate + 资产数据范围复核，三态统一文案 - 读侧：卡/设备列表与详情按页一次 IN 聚合；两类导出补「关联手机号」列并保留历史表头反解兼容 - 脱敏：关联审计走独立动作/资源只写脱敏手机号；访问日志手机号类字段脱敏 - 同步主 Spec openspec/specs/phone-asset-association 并归档 AUG26-009，补齐 requirement-evidence 与入口矩阵，context-health 通过	2026-09-15 11:54:56 +08:00
break	93e072e1e2	feat(换货): AUG26-005 换货业务数据迁移状态与失败恢复 ... - 新增成对迁移 000222：tb_exchange_order 增加非空 migration_status 与 migration_failure_reason，按既有 migrate_data/migration_completed 回填历史， 并加四值 CHECK 约束，不新增索引 - 模型与常量定义四种迁移状态及中文名称，保留既有布尔字段兼容语义 - 物流换货创建恒 not_migrated，发货按请求落 pending/not_migrated， 完成成功写 migrated/not_migrated 并清空失败原因、同步兼容字段 - 直接换货创建即完成，任一步失败整体回滚，不持久化换货单、不产生 failed - 迁移失败回滚全部业务修改后，在独立短事务内条件更新 failed 与安全失败原因 并写失败审计，RowsAffected 为 0 时跳过状态写入但仍写审计 - failed 物流单重试仅限超级管理员或平台用户，授权以锁内 FOR UPDATE 判定为准， 重试从钱包余额起整表重跑；非 failed 单沿用既有完成门禁 - 列表与详情返回迁移状态与中文名称，仅 failed 返回失败原因；既有三字段保持兼容 - 换货导出在「状态」列后新增中文「迁移状态」列，不导出失败原因 - 同步 order-refund-exchange 主 spec 与验证证据，归档本 Change - 登记 KNOWN-ISSUE-001：既有标签复制 OnConflict 未声明部分索引谓词（42P10）， 旧资产带标签时迁移最后一步失败，待另立变更修复	2026-09-14 18:32:26 +08:00
break	c7f9e005af	feat(业务用户组): AUG26-003 业务用户组与店铺负责人分组导入 ... - 迁移 000221：新增 tb_business_user_group、tb_business_user_group_member、tb_shop_business_owner_import_task，成员一账号一行由部分唯一索引保证，店铺所属组按当前负责人实时推导，不回填历史分组。 - 用户组 CRUD、成员改组/清空归属、店铺批量交接（原子失败不部分写入）。 - 店铺负责人 CSV 导入任务：逐行独立事务、逐行明细、任务级与行级失败分离。 - 读侧推导与筛选：未分组、业务线、停用组可筛出并带停用标记。 - 补齐操作审计动作与资源、openapi 清单、发布门禁巡检表清单。 - 归档 add-shop-salesperson-groups 变更并同步 openspec/specs/business-user-group，补齐 AUG26-003 验证证据链。	2026-09-14 16:51:44 +08:00
break	1aa4eacee2	feat(退款分佣): 佣金回溯明细替换全额失效并补齐读侧与导出 ... 用 PRD 2.14 语义整体替换退款佣金「整单全额失效」实现：原佣金保持已发放不变， 回溯事实落在新表 tb_commission_clawback_record 的负数、不可提现明细上。 - 新增成对迁移 000220 建 tb_commission_clawback_record，唯一约束 (refund_id, original_commission_id) 为权威幂等键，附店铺+时间/原佣金/订单索引。 - 回溯用例（internal/service/refund/clawback.go）：准入仅由退款申请状态、审批异常 标记与退款方式决定；金额按分整数计算，分母取冻结实收（缺失回落审批尝试）、 分子原路取渠道成功金额，乘法用 math/big 中间量，舍入差自末条起向前补差； 终态判据要求订单佣金已离开待计算且不存在 status IN (1,2,99) 的记录。 - 三层幂等：唯一约束兜底、佣金行行锁 + 钱包乐观锁、commission_deducted 仅作投影 并带 WHERE commission_deducted = false 条件置位；闭合三结果为已回溯、无需回溯、 审批异常转人工。 - 事务内顺序固定：锁提现申请行 → 锁尝试行 → 解冻冻结 → 置驳回 → 插回溯明细 → 扣 balance（允许为负）→ 写负数流水 → 审计；删除旧全额失效写入与其两个审计调用点， refund.invalidate_commission 仅保留常量与注册供历史审计读取。 - 读侧：佣金明细列表 status 筛选透传，两表 UNION ALL 合并分页并以 source ASC 作 末位次序键；新增佣金明细详情接口并同步路由与 OpenAPI 装配。 - 导出：新增 commission_record 场景（白名单、exporter 注册、DTO oneof、DataSource 与列定义），粒度为佣金记录，原佣金与回溯各一行，金额保持分且可为负。 - 新增退款佣金回溯周期补偿任务（@every 1m / MaxRetry(3) / Timeout(10m) / Unique(10m)，独立队列），保留启动时补偿扫描，判据与既有实现一致。 Refs: AUG26-012	2026-09-14 13:40:34 +08:00
break	67893617fe	feat(退款): AUG26-006 补充当前退款套餐已用量与总量 ... 补齐 PRD §2.3.1「退款管理补充字段」：退款列表、详情与导出新增 「当前退款套餐已用量」与「当前退款套餐总量」两个纯展示字段。 - 套餐定位口径与退款套餐失效保持一致，按优先级取唯一一条： 冻结的 package_usage_id（且属于该订单）→ 订单主套餐 → 订单任一套餐， 同级按标识升序。不按当前世代或当前生效套餐推断；不按套餐状态过滤， 使退款后套餐转已失效时仍能回看用量。 - 列表与详情用固定两次查询批量解析（按标识、按订单），查询次数不随条数增长； 详情复用同一函数。解析不到套餐或记录已物理删除时返回 0，不阻断读取。 - 导出新增两列并改用同一优先级的 LATERAL 取法，不再依赖只按 r.package_usage_id 的 join——生产库 1296 条退款仅 157 条带该字段，旧取法会让多数行显示零值。 - 不改变退款金额校验、冻结实收、套餐失效、接续、停机与佣金回溯任何规则。 验证：测试库 junhong_cmp_test 实测冻结记录、订单主套餐回退、记录缺失返回 0 三项 解析场景与「4 条退款固定 2 次查询」；并以同批 43 条退款对拍 Go 解析器与导出 SQL， 口径不一致 0 条；导出 43 行列数与表头一致。无迁移、无接口路径变化。	2026-09-14 12:11:55 +08:00
break	09abee9778	docs(归档): 归档退款方式与原路退款变更并同步主规格 ... - 将 add-refund-methods-and-original-route-refunds 归档为 2026-09-14-add-refund-methods-and-original-route-refunds。 - 合并两份 delta 到主规格： * order-refund-exchange：改写「订单、退款与换货状态门禁」，新增「退款实收金额与方式矩阵」 「企业微信唯一终审与审批尝试重提」「原路退款渠道能力与执行」「退款权益与订单状态时点」 「退款终态事实与失败分类」五项行为要求。 * merchant-payment-routing：改写「商户与微信授权配置管理」与「新支付商户快照与历史兼容」 （删除「不得新增渠道退款能力」与「不新增富友退款」，改由退款能力按商户凭证执行； 微信 v2 客户端证书改为可选凭证键）。 - 同步上下文健康检查证据链与入口矩阵：为新要求登记证据行，并把退款创建、重提、 企微审批回调、退款详情与 refund:channel:recovery 任务与对应要求双向关联。	2026-09-14 12:00:35 +08:00
break	ba0855d9eb	feat(退款): AUG26-006 退款方式选择与原路退款 ... 按 PRD 2.3/2.4/2.5 落地套餐退款的方式矩阵与原路渠道退款： - 退款申请派生并冻结权威实收金额（线上取原成功支付记录，钱包/线下取订单实际收款）， 提交人不可填写或修改；按来源支付方式生成可选方式矩阵并在创建、提交、执行前重复校验。 - 审批切换为「每次提交一条不可变审批尝试记录 + 独立企业微信审批实例」，业务标识取尝试 记录主键；终态消费按尝试记录优先、退款申请兜底双读，兼容存量无实例与已关联实例申请。 新增活动退款部分唯一索引 (order_id) WHERE status IN (1,5,6)。 - 本地人工终审保持既有开关，补齐通过入口的 approval_instance_id IS NULL 守卫，使三个 入口一致拒绝已关联审批实例的申请；重提按尝试模式重写（仅已拒绝/已退回/原路失败且无异常）。 - 权益时点：企微通过事务写退款终态、按方式确定的订单态、钱包回款、员工账单冲销与可靠 失效事实；套餐失效/接续/停机仍由既有可靠机制最终一致执行，不把外部调用放入资金事务。 订单支付状态按方式置位：凭证退款与退回原钱包在企微通过时置已退款，原路须渠道明确成功。 - 按官方契约实现微信直连 v3、微信 v2（双向证书）、富友（/commonRefund 与 /refundQuery）、 支付宝四类原路退款；能力只由服务商类型与退款必需凭证完整性决定，无人工开关。 渠道请求号在提交时冻结到尝试记录，并以 channel_submitted_at 条件认领保证资金动作至多 提交一次（重复投递只查询不二次提交）；不向任何渠道传递退款结果通知地址。 - 新增 refund:channel:recovery 恢复任务只查询回填；本地查询窗口超期（富友 72 小时、 微信 v2 7 天）转原路退款失败、渠道状态已失败、分类超时未知并置异常转人工，不放行自动 重提以避免重复退款。 - 同步退款 DTO/导出/审计资源与审计查询关联、商户凭证文档，并修正 fuiou 集成契约文档。 迁移 000218（退款尝试与渠道退款事实）、000219（微信 v2 客户端证书凭证）成对提供， 未修改既有迁移；测试库 junhong_cmp_test 完成 up/down/up 与行为核对，未调用真实渠道。	2026-09-14 11:55:16 +08:00
break	315a7de3e4	docs(归档): 归档代理自充支付方式与员工代收款路由前缀两个变更 ... - add-agent-self-recharge-payment-methods 归档为 2026-09-11-add-agent-self-recharge-payment-methods，delta 应用后主规格 agent-funds-commission 完成 1 条 Requirement 改名并新增 4 条 Requirement - 在可达操作索引补充代理自充支付方式配置与付款凭证识别共 3 个端点 - 同步 requirement-evidence.json 与 entry-capability-requirement-matrix.json 证据链 - fix-employee-collection-route-prefix 归档为 2026-09-11-fix-employee-collection-route-prefix 并勾选任务 2.5 门禁：context-health 通过、openspec validate --all 40 passed / 0 failed、doctor healthy	2026-09-11 15:50:15 +08:00
break	e687a266e6	补齐员工代收款账单能力证据链与可达操作索引	2026-09-11 15:20:21 +08:00
break	dc4e0d4103	归档支付商户池变更并同步主规格	2026-09-10 12:03:28 +08:00
break	1e776da292	补齐上下文健康检查证据链	2026-09-10 11:39:56 +08:00
break	a9e2302f7c	1	2026-09-10 10:53:07 +08:00
break	46c8e819df	修改相关证据	2026-08-18 16:30:16 +08:00