准备提案

docs/7月迭代/README.md

@@ -9,6 +9,7 @@
 - [7月迭代禅道研发需求拆分表](./7月迭代禅道研发需求拆分表.md)
 - [7月迭代禅道研发需求逐条录入稿](./7月迭代禅道研发需求逐条录入稿.md)
 - [七月迭代 AI 实施与验收操作手册](./七月迭代-AI实施与验收操作手册.md)
+- [七月迭代测试与业务交付手册](./七月迭代测试与业务交付手册.md)
 - [七月迭代人工验收清单](./七月迭代人工验收清单.md)
 
 评审、开发和验收均以标准评审稿为准。独立稿用于解释方案来源；与标准稿冲突时，标准稿优先。

docs/7月迭代/七月迭代测试与业务交付手册.md

@@ -0,0 +1,543 @@
+# 七月迭代测试与业务交付手册
+
+> 适用人员：业务验收人员、产品人员、测试人员、实施人员。  
+> 文档版本：2026-07-28。  
+> 使用方式：先阅读“开始前准备”，再按业务专题逐项操作。每完成一项，在对应复选框中打勾并保存证据。
+
+## 一、这次交付了什么
+
+本次七月迭代主要解决以下业务问题：
+
+- 店铺、代理、平台账号之间的数据权限和业务员归属。
+- 套餐授权、生效、续费、预计到期和临期提醒。
+- 卡和设备的实名流程、支付方式、状态同步及卡片限速。
+- 代理充值、信用额度、退款、企业微信审批和站内通知。
+- 换货、批量订购、设备批量分配和统一导出。
+- 订单、退款、充值、换货列表缺失的提交人、资产标识和审批状态。
+
+### 1.1 本次可以验收的业务专题
+
+| 专题 | 需求编号 | 一句话说明 |
+| --- | --- | --- |
+| 店铺管理 | #41、#60、#96 | 店铺可限制 C 端新登录、按联系电话查询并绑定平台业务员 |
+| 套餐管理 | #40、#43、#46、#55 | 批量授权套餐、设置生效条件、历史续费并展示预计最终到期时间 |
+| 临期提醒 | #33 | 查询 0～15 天临期资产，并在 15/7/3 天产生站内通知 |
+| 实名与支付 | #48、#53、#62 | 按卡/设备筛选实名状态，配置实名顺序和允许的支付方式 |
+| 充值与钱包 | #34、#38、#97 | 代理在线充值、平台线下代充、信用额度和低余额提醒 |
+| 退款与企微 | #35、#37、#57、#189 | 企微审批驱动退款，退款中禁止换货，换货后的套餐权益可正确失效 |
+| 换货 | #45、#86、#98、#188 | 新旧资产独立查询、换货链、继承店铺和 C 端通知 |
+| 批量业务 | #36、#49 | CSV 批量订购套餐、设备批量分配店铺或套餐系列 |
+| 导出 | #42 | 六类业务数据进入统一异步导出任务 |
+| 卡业务 | #47、#94 | 卡片固定档位限速、状态轮询及运营商回调 |
+| 列表字段 | #44、#181、#182 | 补齐提交人、审批状态、订单渠道和资产标识 |
+
+### 1.2 验收前必须知道的已知边界
+
+以下内容不是测试人员操作错误：
+
+1. **角色级导出字段权限尚未实现。** 当前统一导出可以按账号的数据范围过滤，但不能为不同角色配置不同导出列。本项应登记为“已知未交付”，不能判定为通过。
+2. 退款和充值列表稳定展示提交人及审批状态，但暂不直接展示企微每一个审批节点的具体审批人。
+3. 店铺关闭 C 端登录后，只阻止新的登录，不会强制踢出已经登录的用户。
+4. 卡片限速不保存本地当前档位；出现“结果未知”时，需要向 Gateway 运维人员核对。
+5. CSV 批量任务允许部分成功，任务详情中的逐行结果是最终依据。
+6. 下架套餐续费没有单独的“续费接口”，仍使用原有创建订单流程。
+
+### 1.3 本次明确不验收的内容
+
+- 原路退款。
+- 聚水潭对接。
+- 卡与设备跨品类换货及补差价。
+- 代理分销码、佣金提现。
+- H5 首页隐藏设备下 ICCID。
+- 停机阈值显示、资产详情敏感字段调整、授权列表样式调整。
+- 新建一套本地审批系统；审批节点和审批人规则仍在企业微信后台配置。
+
+## 二、先认识测试账号
+
+| 账号类型 | 可以做什么 | 本手册中的简称 |
+| --- | --- | --- |
+| 超级管理员 | 配置系统、企微、支付方式并查看全平台数据 | 超管 |
+| 平台账号 | 处理平台业务，可查看平台授权范围内的数据 | 平台账号 |
+| 平台业务员 | 平台账号的一种，可绑定为店铺业务员并接收相关通知 | 业务员 |
+| 代理账号 | 只能查看自己店铺及下级店铺数据 | 代理账号 |
+| 店铺账号 | 属于某个店铺的账号，同一店铺可以有多个有效账号 | 店铺账号 |
+| 企业账号 | 只能访问企业业务范围，不得访问代理充值等后台功能 | 企业账号 |
+| 个人账号 | C 端使用卡或设备的个人客户 | 个人账号 |
+
+> “店铺账号”不是“主账号”。通知要求写“全部有效店铺账号”时，同一店铺所有启用账号都必须收到。
+
+## 三、开始前准备
+
+### 3.1 环境准备
+
+由实施或开发人员确认：
+
+- [ ] API 服务可以正常访问。
+- [ ] Worker 已启动，并与 API 使用同一个 Redis/Asynq。
+- [ ] 数据库迁移已经执行到当前发布版本。
+- [ ] 对象存储可上传和下载 CSV、凭证及导出文件。
+- [ ] 企业微信测试应用、可信 IP、回调地址和模板已经配置。
+- [ ] Gateway 测试环境可以接收卡片限速请求。
+- [ ] 运营商回调开关只在对应测试环境联通后开启。
+
+### 3.2 账号和数据准备
+
+建议准备以下最小数据，不要直接使用生产数据：
+
+- [ ] 1 个超管账号、1 个普通平台账号。
+- [ ] 2 个启用的平台业务员，其中 1 个稍后用于换绑测试。
+- [ ] 代理店铺 A、A 的下级店铺 A1、与 A 无关的店铺 B。
+- [ ] A、A1、B 各至少 2 个启用店铺账号，再准备 1 个禁用店铺账号。
+- [ ] 代理店铺 A 的代理账号，以及店铺 B 的代理账号。
+- [ ] 至少 2 张卡和 2 台设备，分别归属 A、A1、B，并准备个人账号绑定。
+- [ ] 可购买套餐、下架套餐、购买即生效套餐、实名后生效套餐各 1 个。
+- [ ] 预计最终到期日分别为 15、7、3、1 天的资产，以及 1 个已过期资产。
+- [ ] 一笔可退款订单、一笔正在退款的订单、一笔已换货订单。
+- [ ] 代理主钱包余额高于 100 元，并可通过测试消费降到 100 元以下。
+
+### 3.3 每条用例怎样算通过
+
+一条用例只有同时满足以下条件才算通过：
+
+1. 页面提示正确。
+2. 刷新页面后数据仍然正确。
+3. 换一个无权限账号不能看到或操作该数据。
+4. 重复点击、重复回调或重复触发不会重复扣款、退款、入账或通知。
+5. 异步任务最终进入成功、部分成功或明确失败状态，不能长期卡在处理中。
+
+发现问题时至少保存：账号、时间、操作页面、输入内容、预期结果、实际结果、完整截图和请求 ID。
+
+## 四、业务验收步骤
+
+## 4.1 店铺查询、业务员和 C 端登录限制
+
+### 用例 A：联系电话精确查询
+
+1. 使用平台账号进入店铺列表。
+2. 输入一个已存在店铺的完整 11 位联系电话并查询。
+3. 再输入少一位、多一位、包含字母和不存在的号码。
+
+预期结果：
+
+- [ ] 完整号码只返回联系电话完全相同的店铺。
+- [ ] 非法号码给出明确提示，不进行模糊查询。
+- [ ] 代理账号只能查到自己及下级店铺，不能查到无关店铺 B。
+
+### 用例 B：绑定和换绑店铺业务员
+
+1. 新建或编辑店铺 A，选择启用的平台业务员甲。
+2. 在店铺列表和详情查看业务员名称及状态。
+3. 将业务员改为乙，再清空业务员。
+4. 尝试选择禁用账号、代理账号或企业账号。
+
+预期结果：
+
+- [ ] 创建、编辑、换绑和清空后页面立即正确回显。
+- [ ] 只能选择启用的平台账号。
+- [ ] 代理账号不能给店铺指定其他业务员。
+- [ ] 换绑后，后续新通知只发送给当前有效业务员。
+
+### 用例 C：禁止店铺资产新登录 C 端
+
+1. 打开店铺 A 的“禁止 C 端登录”开关。
+2. 使用 A 名下卡和设备重新发起 C 端登录。
+3. 使用 B 名下资产登录。
+4. 关闭开关后再次使用 A 名下资产登录。
+
+预期结果：
+
+- [ ] A 名下资产不能获得新的 C 端登录令牌。
+- [ ] B 名下资产不受影响。
+- [ ] 关闭开关后 A 名下资产可重新登录。
+- [ ] 开关不会主动踢出已经登录的用户。
+
+## 4.2 套餐授权、生效、续费和预计到期
+
+### 用例 A：系列套餐批量授权
+
+1. 给店铺 A 首次授权一个套餐系列，并一次选择多个套餐。
+2. 再次进入授权页面，新增套餐、修改价格、移除一个套餐。
+3. 尝试重复选择已经授权的套餐。
+
+预期结果：
+
+- [ ] 首次授权必须至少包含一个套餐。
+- [ ] 单次可以提交多个套餐，价格正确保存。
+- [ ] 已授权套餐不能重复选择。
+- [ ] 移除后只影响该授权关系，不删除套餐本身。
+
+### 用例 B：套餐生效条件
+
+1. 分别创建“购买即生效”和“实名后生效”的套餐。
+2. 分配给店铺时，分别测试跟随默认值和覆盖默认值。
+3. 用资产购买套餐，再修改套餐或店铺分配设置。
+
+预期结果：
+
+- [ ] 页面正确显示套餐默认值、店铺覆盖值和最终生效值。
+- [ ] 新购买记录保存购买时的生效规则快照。
+- [ ] 后续修改配置不会改变历史订单和已购买套餐的规则。
+
+### 用例 C：下架套餐的历史续费
+
+1. 让资产先购买套餐 P，再将 P 下架。
+2. 使用从未购买过 P 的新资产尝试购买。
+3. 使用历史购买过 P 且仍具备续费资格的资产续费。
+
+预期结果：
+
+- [ ] 下架套餐不出现在普通新购列表中。
+- [ ] 新资产不能绕过页面直接购买下架套餐。
+- [ ] 符合历史使用资格的资产仍能通过原创建订单流程续费。
+
+### 用例 D：预计最终到期时间
+
+分别查看无套餐、单套餐、多个排队套餐和等待实名激活的资产。
+
+预期结果：
+
+- [ ] 单套餐显示该套餐预计结束时间。
+- [ ] 多个排队套餐显示全部套餐使用完后的预计最终到期时间。
+- [ ] 无法确定激活时间时不伪造一个确定日期。
+- [ ] 后台列表、后台详情和 C 端展示口径一致。
+
+## 4.3 套餐临期列表和通知
+
+### 用例 A：实时临期列表
+
+进入后台临期资产页面，检查准备好的 15、7、3、1 天及已过期资产。
+
+预期结果：
+
+- [ ] 只展示剩余 0～15 个上海自然日且能够精确计算的资产。
+- [ ] 0～3 天为最高优先级并排在前面，4～7 天和 8～15 天显示不同等级。
+- [ ] 已过期、无套餐和无法预计到期的资产不进入临期列表。
+- [ ] 卡、设备数量汇总和列表筛选结果一致。
+- [ ] 代理账号只能看到自己及下级店铺的资产。
+
+### 用例 B：15/7/3 天临期通知
+
+由超管触发一次临期扫描，等待 Worker 和通知任务处理完成。
+
+预期结果：
+
+- [ ] 只有当天恰好剩余 15、7、3 天的资产产生通知。
+- [ ] 所属店铺的全部启用店铺账号都收到通知，不只发送给主账号。
+- [ ] 当前有效绑定的平台业务员收到通知。
+- [ ] 资产绑定的启用个人账号收到 C 端通知。
+- [ ] 禁用账号、已换绑业务员和无关账号不收到通知。
+- [ ] 通知正文明确是哪张卡或哪台设备、到期日期以及“即将过期”状态。
+- [ ] 对同一批数据再次触发扫描，不产生重复通知。
+
+手动触发接口见[附录](#六附录给实施和接口测试人员)。临期列表本身是实时查询；通知扫描不是实时触发，而是定时或手动触发。
+
+## 4.4 实名状态和 H5 流程
+
+### 用例 A：卡和设备实名状态筛选
+
+1. 在卡列表分别选择全部、已实名、未实名。
+2. 在设备列表执行相同操作。
+3. 给设备绑定已实名卡、解绑或更换成未实名卡后重新筛选。
+
+预期结果：
+
+- [ ] 卡按自身实名状态进入正确结果。
+- [ ] 设备绑定的任意一张有效卡已实名时，设备视为已实名。
+- [ ] 解绑和换卡后设备实名状态随有效绑定关系变化。
+- [ ] 翻页和刷新后筛选条件仍然有效。
+
+### 用例 B：三种购买与实名顺序
+
+分别配置并验证：无需实名、先实名后购买、先购买后实名。
+
+预期结果：
+
+- [ ] 无需实名：用户可以直接购买和使用业务允许的功能。
+- [ ] 先实名后购买：未实名时不能进入购买，实名后可以购买。
+- [ ] 先购买后实名：可以先完成购买，再引导实名激活。
+- [ ] 卡和设备支持批量配置，单批最多 500 条且失败时整批不生效。
+- [ ] 设备与下属卡规则冲突时，以设备返回的最终规则为准。
+
+## 4.5 卡和设备支付方式
+
+1. 超管分别给卡和设备配置钱包、微信、支付宝的允许组合。
+2. 使用卡和设备进入 C 端购买及充值页面。
+3. 创建订单后再修改系统配置，然后尝试支付旧订单。
+4. 直接伪造一个当前不允许的支付方式请求。
+
+预期结果：
+
+- [ ] 卡和设备展示各自允许的支付方式，至少保留一种。
+- [ ] 强充和普通充值场景不会错误展示钱包支付。
+- [ ] 订单保存创建时选择的支付方式。
+- [ ] 支付时后端再次校验；配置已变化的旧订单提示取消并重建。
+- [ ] 直接请求不能绕过后端限制。
+
+## 4.6 代理充值、信用额度和余额提醒
+
+### 用例 A：代理在线充值与平台线下代充值
+
+1. 代理账号为自己的主钱包创建在线充值单并完成支付。
+2. 平台账号为目标店铺创建线下代充值，上传凭证并进入企微审批。
+3. 企微通过、拒绝各测试一次，并重复推送相同最终状态。
+
+预期结果：
+
+- [ ] 代理在线充值不能替其他无关店铺充值。
+- [ ] 平台线下代充必须等待企微通过后入账。
+- [ ] 拒绝后不入账；重复回调不重复入账。
+- [ ] 到账通知发送给该店铺全部有效店铺账号和当前有效平台业务员。
+- [ ] 通知正文明确“哪个店铺充值了多少钱”，金额精确到分。
+
+### 用例 B：代理充值数据权限
+
+1. 准备店铺 A、A1、B 的充值订单。
+2. 使用 A 的代理账号打开充值列表。
+3. 搜索 B、直接打开 B 的订单详情，并查询 B 的支付状态。
+4. 使用平台账号查看同一批订单。
+
+预期结果：
+
+- [ ] A 的代理账号只能看到 A 和下级 A1 的订单。
+- [ ] 筛选 B 时返回空结果，不能通过参数扩大权限。
+- [ ] 直接访问 B 的详情和支付状态时返回无权限或资源不存在。
+- [ ] 平台账号可以按业务权限查看全量订单。
+- [ ] 企业账号不能访问代理充值功能。
+
+### 用例 C：信用额度
+
+1. 给某角色设置新建店铺默认信用额度。
+2. 用该角色创建新店铺，检查主钱包额度。
+3. 修改角色默认额度，再检查已有店铺。
+4. 单独修改已有店铺的信用开关和额度，并测试扣款、冻结、退款和充值。
+
+预期结果：
+
+- [ ] 角色默认额度只影响之后新建的店铺。
+- [ ] 已有店铺必须单独调整，不会被角色配置追溯覆盖。
+- [ ] 可用余额允许在信用边界内显示负数。
+- [ ] 超过信用边界时扣款失败，充值和退款回充后金额正确。
+
+### 用例 D：余额首次跌破 100 元提醒
+
+1. 将代理主钱包现金可用余额从 100 元以上消费到 100 元以下。
+2. 在低余额状态继续消费。
+3. 充值到 100 元以上，再次消费到 100 元以下。
+
+预期结果：
+
+- [ ] 第一次跌破 100 元时，当前有效业务员收到一条站内通知。
+- [ ] 持续低于 100 元时不重复通知。
+- [ ] 回升后再次跌破，可以再次通知。
+- [ ] 禁用或已换绑业务员不收到后续新通知。
+
+## 4.7 企业微信审批和退款
+
+### 用例 A：企业微信基础配置
+
+按以下顺序操作：保存应用 → 测试连接 → 同步成员 → 选择默认发起人 → 绑定系统账号 → 配置退款模板 → 配置线下代充值模板。
+
+预期结果：
+
+- [ ] 只能从应用可见成员中选择默认发起人和绑定成员。
+- [ ] 模板控件 ID、类型、选项和必填项不匹配时不能保存。
+- [ ] 代理提交时，企微可由默认成员代发起，但本地提交人仍是实际代理账号。
+- [ ] 本系统不提供审批节点和审批人规则编辑功能。
+
+线下代充值允许映射的业务字段为：`recharge_no`、`shop_id`、`shop_name`、`amount`、`amount_cent`、`payment_voucher_key`、`remark`、`submitter_id`、`submitter_name`。出现“当前业务不支持的字段”时，先核对是否填写了该列表之外的字段。
+
+### 用例 B：退款审批和最终处理
+
+1. 为可退款订单提交退款申请。
+2. 分别在企微完成通过、拒绝、撤销。
+3. 对同一审批结果重复回调或主动同步。
+4. 检查钱包回充、套餐失效、佣金和退款状态。
+
+预期结果：
+
+- [ ] 页面展示真实提交人、审批来源和中文审批状态。
+- [ ] 企微记录不显示本地“通过/驳回”按钮。
+- [ ] 通过后退款只执行一次，整单状态、钱包、套餐和佣金处理一致。
+- [ ] 拒绝或撤销后不会退款。
+- [ ] 退款完成通知发送给该店铺全部有效店铺账号和当前有效平台业务员。
+- [ ] 重复回调、轮询或同步不重复退款和通知。
+
+### 用例 C：退款与换货交叉场景
+
+1. 给资产创建未终结退款，再尝试创建换货。
+2. 将退款拒绝、撤销或处理完成，再次创建换货。
+3. 对已换货且套餐已迁移的订单退款。
+
+预期结果：
+
+- [ ] 存在活跃退款时直接拒绝换货，不产生半成品换货单。
+- [ ] 退款终结后允许重新发起换货。
+- [ ] 换货后退款能找到新资产上的对应套餐权益并正确失效。
+- [ ] 只失效该退款订单产生的权益，不影响其他套餐。
+
+## 4.8 换货查询、继承和通知
+
+1. 在换货列表分别用旧资产和新资产的 ICCID、接入号或虚拟号搜索。
+2. 同时填写新、旧资产条件。
+3. 完成一次同品类换货，检查新资产店铺归属。
+4. 查看旧资产、新资产和中间资产的换货链。
+5. 创建物流换货单并使用个人账号查看通知。
+
+预期结果：
+
+- [ ] 新、旧资产搜索框互不混淆，同时填写时按两个条件共同过滤。
+- [ ] 换货完成后新资产自动继承旧资产所属店铺，前端不能另选目标店铺。
+- [ ] 重复完成不会重复迁移，不能越权换入其他店铺资产。
+- [ ] 详情正确展示前代、后代；无权限节点不可跳转。
+- [ ] 创建物流换货单后，C 端收到换货弹窗或站内通知。
+
+## 4.9 批量订购套餐
+
+1. 下载或制作只有一列“资产标识”的 UTF-8 CSV。
+2. 上传 CSV，在页面统一选择一个套餐和一种支付方式。
+3. 文件中同时放入成功数据、重复数据、无权限数据和不存在的数据。
+4. 提交任务，刷新列表并查看详情。
+5. Worker 处理中重启一次，再查看任务恢复结果。
+
+预期结果：
+
+- [ ] CSV 中不填写代理、套餐和支付方式，最多 1000 行、10MB。
+- [ ] 每一行都有成功、失败或跳过结果和明确原因。
+- [ ] 一行失败不影响其他合法行。
+- [ ] 重复执行或任务恢复不会重复下单、扣款或发放套餐。
+
+## 4.10 设备批量分配
+
+1. 制作只有一列“设备标识”的 UTF-8 CSV，可填写 VirtualNo、IMEI 或 SN。
+2. 分别创建“分配店铺”和“设置套餐系列”任务。
+3. 查看任务列表和详情。
+4. 放入无权限设备、重复设备、不存在设备和已正确分配设备。
+
+预期结果：
+
+- [ ] 创建时正确保存操作类型和目标 ID。
+- [ ] 任务列表返回操作名称、目标 ID、状态名称和进度。
+- [ ] 逐行结果能区分成功、失败和跳过。
+- [ ] 代理只能处理自己权限范围内的设备，不能越权分配 B 的设备。
+- [ ] 重试不会重复分配或产生错误的套餐系列关系。
+
+## 4.11 统一导出
+
+分别对 IoT 卡、套餐、代理主钱包流水、代理充值、退款和换货创建 CSV、XLSX 导出任务。
+
+预期结果：
+
+- [ ] 导出任务异步执行，可以查看进度、失败原因和下载地址。
+- [ ] 平台账号和代理账号导出的数据行符合各自数据权限。
+- [ ] 下载链接受保护且过期后不能继续使用。
+- [ ] Worker 重启后任务可以恢复，不重复生成错误数据。
+- [ ] 角色级导出字段权限当前不得勾选“通过”，应记录为已知未交付。
+
+## 4.12 卡片限速、复机和状态同步
+
+### 用例 A：卡片固定档位限速
+
+1. 进入 IoT 卡详情，依次选择恢复不限速及固定档位。
+2. 使用无权限账号操作其他店铺卡。
+3. 模拟 Gateway 明确失败和超时。
+
+预期结果：
+
+- [ ] 只有 IoT 卡有固定档位入口，设备页面没有限速入口。
+- [ ] 请求只使用卡 ICCID，不使用设备号代替。
+- [ ] 越权操作被拒绝。
+- [ ] 明确失败显示失败；超时显示“结果未知”，不盲目自动重试。
+
+### 用例 B：行业卡复机和状态同步
+
+1. 使用未实名行业卡执行复机。
+2. 通过轮询、手动刷新、业务操作和已开启的运营商回调改变卡状态。
+3. 检查卡、设备和详情页面状态。
+
+预期结果：
+
+- [ ] 本轮口径下，行业卡不因未实名而被阻止复机。
+- [ ] 各入口写入相同的公共状态，不出现列表与详情互相矛盾。
+- [ ] 要求 ICCID 的 Gateway 调用不得传设备号。
+- [ ] 未完成真实联调的运营商回调开关保持关闭。
+
+## 4.13 订单、退款、充值和换货列表字段
+
+抽查卡订单、设备订单、退款、充值和换货记录。
+
+预期结果：
+
+- [ ] 卡的资产标识显示 ICCID。
+- [ ] 设备优先显示虚拟号，没有虚拟号时显示 IMEI，不使用 SN 冒充。
+- [ ] C 端订单正确显示订单渠道或购买角色。
+- [ ] 退款、充值、换货显示真实提交人 ID 和名称。
+- [ ] 退款和线下充值显示审批来源、审批状态和中文状态名称。
+- [ ] 历史本来没有快照的数据保持为空，不伪造错误值。
+
+## 五、业务人员最终签字清单
+
+业务负责人不需要检查数据库，只需确认以下结果：
+
+- [ ] 不同账号看到的数据范围正确，无跨店铺越权。
+- [ ] 充值、退款、换货、套餐和钱包金额正确，无重复处理。
+- [ ] 企微通过、拒绝、撤销后的系统结果符合业务预期。
+- [ ] 套餐生效、下架续费、预计到期和临期口径符合业务约定。
+- [ ] 临期、充值、退款通知发送给正确的人，正文能看懂具体业务对象。
+- [ ] 批量任务允许部分成功，失败原因足够业务人员自行处理。
+- [ ] 本期不做项和已知缺口已经确认，不作为上线阻塞项或已另行排期。
+
+建议使用以下结论之一：
+
+- **通过**：全部必测项通过，无阻塞问题。
+- **有条件通过**：只有已知缺口或已有明确排期的非阻塞问题。
+- **不通过**：存在越权、错账、重复扣款/退款/入账、审批终态错误、通知错人或核心流程不可用。
+
+## 六、附录：给实施和接口测试人员
+
+### 6.1 手动触发临期通知扫描
+
+```http
+POST /api/admin/expiring-assets/reminder-scan
+Authorization: Bearer <超级管理员Token>
+```
+
+接口只负责立即提交与每日定时任务相同的扫描任务。接口返回成功不等于通知已经生成，必须继续等待 Worker 和 Outbox 处理。
+
+### 6.2 常用排查顺序
+
+1. 页面是否收到统一响应：`{code,msg,data,timestamp}`。
+2. 请求账号的类型、店铺 ID 是否正确。
+3. API 和 Worker 是否连接同一个 Redis/Asynq。
+4. 异步任务是否进入成功、部分成功或失败终态。
+5. 企业微信、Gateway、对象存储是否有明确外部错误。
+6. 通知接收人的账号是否启用、业务员是否仍绑定、个人账号是否仍绑定资产。
+
+### 6.3 问题反馈模板
+
+```markdown
+### 问题标题
+[七月迭代][功能名称] 简要说明问题
+
+- 测试环境：
+- 发生时间：
+- 测试账号及账号类型：
+- 店铺/资产/订单/任务编号：
+- 前置条件：
+- 操作步骤：
+  1.
+  2.
+  3.
+- 预期结果：
+- 实际结果：
+- 是否可以稳定复现：
+- 请求 ID：
+- 截图或录屏：
+```
+
+## 七、参考文档
+
+- [七月迭代人工验收清单](./七月迭代人工验收清单.md)
+- [七月迭代实现与接口对接说明](./七月迭代实现与接口对接说明.md)
+- [七月迭代联调交付说明](./七月迭代联调交付说明.md)
+- [七月迭代技术方案（标准评审稿）](./7月迭代技术方案-标准评审稿.md)
+- [后台 OpenAPI 文档](../admin-openapi.yaml)