企业商户进件与微信开通：已确认任务拆分

状态：用户已确认。2026-09-16 因需求变更（不做一键进件、实名走法人、未完成实名不允许收款）调整为三张工单，同日因用户不再需要测试商户 6666000241335656 关闭其中 02，现为两张并行工单。
日期：2026-09-15 首次发布；2026-09-16 修订两次。

依据：完整规格 与 ADR 0001 的 2026-09-16 修订。

工单

执行规则

两张工单**并行推进、互不阻塞**，不设先后门。开工门槛是“通道能力已被真实接口证明”：微信业务三场景即时入驻成功、延迟入账生效、人才端 AppID 绑定成功都已经在存量商户上验证并归档在 核验证据。

03 接入新增企业商户的分阶段流程：一次收齐资料，之后按阶段手动推进基本进件 → 微信业务开通 → 微信实名认证，两端刷新查看。不做“一次进件即完成收款能力”。

04 交付微信实名认证的发起能力与授权状态闭环，并把它纳入收款就绪判定。按用户决策：**实名走法人**（进件只新增法人手机号一项），**未完成实名与授权前不允许商户收款**。

02 已关闭，不再执行其剩余验收。它的产出不因此作废：三个真实缺陷修复已合入，通道能力已证明，证据已归档。指定存量商户保持“待实名”，不再是任何一票的验收条件或阻塞项。

模拟测试通过、接口受理成功或本地标记成功均不等同于真实验收。ready-for-agent 表示工单可由代理承接，不代表已完成。

每个独立 Issue 包含自身验收条件及共同约束。自动化使用模拟汇付响应，不创建真实商户；真实联调失败先核对原申请，不反复新进件制造控台记录。

执行顺序

1. 04 第一步（已完成）：把恢复路径里的单商户硬编码换成申请单自身的 huifu_id，删除 HuifuOnboardingProgressGateway.openWechat 占位与视图里的过期文案。
2. 04 其余部分：新建实名申请能力、法人手机号字段、授权状态闭环、收款就绪纳入实名。
3. 03：放开分阶段进度的灰度门槛（连同 5 个测试的策略改写），提供“下一步”推进与微信业务开通的商户手动入口。

顺序依据：03 的第三个阶段就是微信实名，先落地 04 才能让 03 的阶段推进接在真能力上。

一处修正：原先把「去掉 RECOVERY_HUIFU_ID、进度按申请单通用」算作 04 的清理，动手后发现站不住。supports() 不只是白名单，它还是「分阶段模型 vs 旧单状态模型」的路由开关：换成「有结算卡且未被拒绝」会同时给**所有**商户切换行为——进件失败不再释放银行卡（MerchantOnboardingRetryReleaseTests 2 项）、回调改走分阶段刷新（MerchantSettlementCallbackIdempotencyTests 3 项），实测 5 个测试会红。那是策略变更，归 03，不是清理。

两张票的冲突面

• 进度服务：04 只改恢复路径内部的 huifu_id 来源；supports() 的灰度策略由 03 放开，04 不动。
• 商户端进件表单：04 加法人手机号，03 加行业与材料校验。04 先落地，03 在此基础上做增量。
• 收款就绪门槛：实现在 04（MerchantPaymentReadinessService 补上微信业务开通与实名/授权）；03 只做验收核对，不重复实现。
• 共享文件：application.yml、AdminBusinessService.java、CONTEXT.md 等只做自己范围内的增量小改，不顺手整理。

确认记录

• 2026-09-15：用户要求降低任务粒度，由六票收敛为两个业务阶段。
• 2026-09-15：用户回复“确认”，批准按两票发布。
• 2026-09-15：用户同意删除冗余的 01 总任务，两张工单直接引用规格；保留原编号及 02 → 03 的依赖。
• 2026-09-16：用户确认需求变更——不做一键进件同时完成收款能力，改为一次性收录资料加分阶段手动推进；扫码授权由本人完成，平台不追求全自动。据此修订 03 口径。
• 2026-09-16：用户确认“实名走法人”（只新增法人手机号字段，不选需要盖章授权函的经办人）与“未完成实名/授权前不允许商户收款”。据此新增 04，并从 02 的阶段切换条件中移除实名，解开死锁。
• 2026-09-16：用户确认不再需要 6666000241335656 做测试。02 关闭（wontfix），03 解除阻塞改为可立即开始，04 的成立理由回到“任何商户要能收款都需要实名”。规格中“先存量、后新商户”的两阶段框架与阶段切换条件整体作废，02 只保留为通道能力的验证来源。