当前方案不能按原提议直接放行。主要问题不是“少几个测试项”，而是：
材料列明：
refund_records但 v1.3 六项增量中没有明确包含：
因此，材料中的“v1.3 覆盖 062-064 全部新表端点”与前文自相矛盾。至少 062 对应的退款深化尚未被清单覆盖。
新增“退款与对账域”作为第 7 项，至少纳入：
7. 退款与对账域：
- refund_records 查询/创建/更新或状态推进端点
- 退款状态机与非法迁移
- 原路退、线下退或人工退的支付语义
- 幂等规则、重复请求、并发退款规则
- 退款与订单/支付/核销/逆账的关联
- 对账单生成、查询、下载及失败重试
- 消息推送触发、重试、补偿和死信
- system 角色人工干预与审计留痕如果上述端点尚未实现，必须明确标记为：
062 退款深化域未闭环，不得宣称 v1.3 覆盖 062-064。
材料只给出模块名称，没有给出完整端点台账。仅凭“CRUD”不能证明端点完整，因为以下内容可能被漏掉：
| 领域 | 当前清单 | 仍需核对 |
|---|---|---|
| 核销 | scan/confirm/stage 查询 | 撤销、过期、重复核销、并发核销、逆账、商户拒单 |
| 内容 | reviews/messages/stories CRUD+阅读计数 | 列表、分页、排序、软删除、审核、举报、计数幂等 |
| 退款 | 未纳入六项 | 退款记录、对账单、推送、重试、人工干预 |
| 民宿申请 | 提交/查询 | 审核、驳回、撤回、重复提交、状态变更通知 |
| 文案 | CRUD | 发布/下线、版本、缓存失效、预览、回滚、审计 |
| 人工改态 | 订单人工改态 | 可改状态白名单、前置状态、后置动作、逆账、审计 |
在签收前必须补一张端点台账，每个端点至少包含：
端点路径
HTTP 方法
所属领域
所属包/迁移
前端或调用方
鉴权角色
请求/响应 Schema
错误码
幂等要求
状态影响
数据库表
审计要求
负责人
验收证据验收条件不能写成“端点归属唯一”，而应改成：
每个端点有且仅有一个业务归属、一个契约定义、一个实现责任人、一个验收证据；不存在未登记端点、重复定义端点和无调用方端点。
当前 v1.3 偏重“端点有没有”，没有充分约束“端点组合起来是否正确”。必须补充以下契约级不变量：
partially_redeemed 后能否退款、取消或再次核销；这些规则材料未涉及，不能假设已经存在。应标记为：
材料未涉及，属于签收前必须补齐的契约内容。
“22→40”本身没有证明质量提升。当前方案存在三个根本缺陷：
每轮从 40 项抽 10 项，意味着关键项可能连续多轮不执行。支付、退款、核销状态机、权限绕过、幂等和数据一致性都不应该随机抽测。
材料要求挑战“抽测漏 L3 风险”，但材料没有定义：
所以当前“深验”没有风险治理基础。结论应为：
L3 分级及其门禁规则：材料未涉及；在此状态下不能证明抽测不会漏 L3。
20 分钟适合作为快速回归，不适合作为支付、核销、退款、迁移和权限链路的深度验证。必须区分：
目前四者混在一起。
以下项目不能抽签，必须每轮执行：
partially_redeemed 迁移；材料没有说明上述项目当前均已存在判据，必须补齐，不能默认 40 项已覆盖。
普通 CRUD、页面字段、非关键展示、低风险文案、非核心统计等，才适合在剩余判据中轮换抽测。
以下场景不能只抽 10 项：
发布前应执行：
40 项全量回归 + 全部 L3 场景 + 核心链路 E2E + 迁移/回滚验证。
材料明确列出的新增项包括迁移、鉴权、核销、MD5、mock 扫描和页面数核对，但以下风险没有被明确覆盖：
尤其是“mock 引用全站扫描”和“MD5 比对”属于辅助证据，不能替代业务正确性验证。种子 MD5 也只能证明文件相同，不能证明数据语义正确。
建议改为：
L3 任一失败：禁止发布，禁止通过体验版门禁。
L2 失败：必须有明确豁免人、修复期限和回滚方案；默认不放行。
L1 失败：可记录后放行，但不得影响核心链路。
证据缺失：按失败处理，不按“未发现问题”处理。
抽测未覆盖 L3：视为未完成验收。“未测”不能等价于“通过”。
材料只写了：
生产更新+真机验证两前置完成后立即执行。
这不够。生产更新本身就是高风险动作，至少还缺：
材料未涉及这些内容，不能默认具备。
只有全部满足才可批准：
材料明确写出：
a端：登录+9 模块全真页面——前端页面接真待排。
这意味着内部体验版如果包含运营人员使用场景，可能出现：
因此必须二选一：
不能以“页面存在但接真待排”的状态进入体验灰度。
材料一方面说：
b端：两段核销接真（284 补丁待一号代推）
另一方面第 5 项说：
262 阿仁两段核销+284 二号补丁的验收复核确认：已验，知悉即可。
这是直接矛盾。补丁尚未完成部署，就不能把补丁后的验收状态写成“已验”。
第 5 项改为：
284 补丁部署完成后，重新执行两段核销、重复核销、部分核销、拒单、逆账和权限验收；部署前的验收仅视为代码/包级验收，不视为集成验收。
“真实商户入驻流跑通 1 例+微信支付沙箱→真实通道凭据”只是必要条件，不是充分条件。对外灰度还必须补：
其中退款、对账、服务费落地情况，材料没有给出足够证据，当前不能批准对外灰度。
服务费口径会影响订单、支付、对账、退款和商户结算。当前把它放在生产更新之后，可能导致：
这是错误的依赖顺序。
凭据不是“验证通过即给变量名”这么简单。必须先确定：
材料未涉及这些控制，不能直接批准生产凭据进入系统。
284 补丁待代推，却写“已验”。必须拆成：
三者不能合并。
先不讨论“批准还是不批准”，先确认以下证据是否齐全：
缺任何一项，结论只能是“暂缓”，不能用口头确认替代。
处理：
商业口径未锁定，不得冻结契约和生产配置。
完成：
重点重验：
partially_redeemed；在此之前，第 5 项不得写“已验”。
不是抽 10 项，而是：
任何 L3 失败、证据缺失或关键链路未测，停止发布。
前提：
“staging 验证 45h+、一条命令”只能作为支持证据，不能替代生产变更控制。
限制为：
凭据必须通过安全密钥管理进入指定环境，不应在决策窗中仅以“变量名”形式放行。真实支付接入前，必须完成：
受控体验版通过，不等于对外灰度通过。对外灰度必须另行确认真实商户入驻、支付、退款、对账、核销、运营后台和止损链路全部闭环。
| 项目 | 原建议 | 修正结论 |
|---|---|---|
| 契约 v1.3 | 可按六项增量执行 | 暂不通过：明确漏退款深化域，先补端点矩阵 |
| 深验 40 项 | 每轮抽 10 项 | 不通过：改为 L3 固定必测、发布前 40 项全量 |
| 受控体验版 | 今晚批准上传 | 有条件批准：先完成 284 部署验收、全量深验、生产回滚门禁 |
| 对外灰度 | 再等一轮 | 方向正确但门槛不完整：补退款、对账、真实回调、运营后台和止损条件 |
| 生产容器更新 | 立即批准 | 后移：商业口径、契约冻结、补丁验收和发布前深验完成后再批 |
| 服务费口径 | 放在生产更新之后 | 前移：先锁定，否则可能引发契约和数据返工 |
| 真实支付凭据 | 验证后给变量名 | 不得直接放行：必须走安全托管、环境隔离和回滚控制 |
| 262/284 验收 | 已验，知悉即可 | 不成立：284 待部署，必须做部署后集成复验 |
今晚最稳妥的结论：不批准无条件生产更新，不批准当前状态下的体验版上传；先补退款契约、完成 284 部署后复验，并执行 L3 固定项+40 项全量验收。