.scratch/merchant-wechat-onboarding/issues/03-new-enterprise-onboarding.md
@@ -11,7 +11,7 @@ - [ ] 进件表单的资料收录以 [04](04-wechat-realname-application.md) 新增的**法人手机号**为准（该字段属于实名的前置，04 不被阻塞可先落地）；04 先落地则直接复用，不重复加字段。 - [ ] 商户可理解适用费率与待补材料，渠道技术参数由平台维护；不复制参考商户独有身份与资质。 - [ ] **分阶段手动推进**：进件完成后向商户提供可执行的“下一步”，商户推进微信支付业务开通；开通完成后推进微信实名认证；每阶段之后刷新查看通道结果。尚未完成的阶段不得显示为完成，缺证据时给出具体缺项。 - [ ] **进度与刷新去掉只服务一张商户的恢复路径**：现有分阶段进度与刷新只对常量 `RECOVERY_HUIFU_ID = "6666000241335656"` 生效（`MerchantOnboardingProgressService.supports()`），随 02 关闭已无使用对象，而新商户需要同一套分阶段视图。按申请单通用地重做（`merchant_onboarding_progress` 已按 `application_id` 建表，结构上支持）；同时决定 `configureDelay`／`advanceDelay` 阶段与 `openWechat` 抛异常的占位是删除还是保留为通用能力。注意**新商户的延迟入账随业务开通请求一并生效**（`delay_flag=Y`／`forced_delay_flag=N` 已在请求里），不需要单独的补配步骤。 - [ ] 复用 04 已经通用化的分阶段进度与刷新（04 的第一项就是去掉只服务一张商户的恢复路径），本票只负责把新商户接入这套视图并提供“下一步”推进，不重复改造进度服务。 - [ ] **微信业务开通的商户手动入口**：当前业务开通是进件后由回调或刷新在服务端静默执行的，存量补开入口 `HuifuOnboardingProgressGateway.openWechat` 仍是抛异常的占位（`"Wechat business profile is not confirmed"`）。需要给商户端与后台提供可推进的入口，同时保留服务端自动路径。 - [ ] 一次提交保存唯一申请关联；基础审核未确认成功前不越过前置条件，确认后继续微信与资金能力办理。 - [ ] 商户端与后台显示一致的基本审核及后续配置状态，提供刷新、具体失败提示和可执行下一步；普通状态读取保持只读。 .scratch/merchant-wechat-onboarding/issues/04-wechat-realname-application.md
@@ -6,6 +6,7 @@ Status: ready-for-agent - [ ] **第一步：清理进度服务的单商户硬编码。** 现有分阶段进度与刷新只对常量 `RECOVERY_HUIFU_ID = "6666000241335656"` 生效（`MerchantOnboardingProgressService.supports()`），随 02 关闭已无使用对象。按申请单通用地重做（`merchant_onboarding_progress` 已按 `application_id` 建表，结构上支持），并处置 `configureDelay`／`advanceDelay` 阶段与 `openWechat` 抛异常的占位。**先清理再往上加实名阶段**，否则本票的实名进度要建在即将删除的代码上。注意新商户的延迟入账随业务开通请求一并生效（`delay_flag=Y`／`forced_delay_flag=N` 已在请求里），不需要单独的补配步骤。 - [ ] 新建实名申请通道适配：调用 `v2.merchant.busi.realname` 发起申请，走法人（`contact_type=LEGAL`），必填法人姓名、法人手机号、法人身份证号；企业另填 `owner` 与 `identification_address`。现有仓库只有 `v2.merchant.busi.realname.query` 查询，提交接口需要新建。 - [ ] 进件表单新增法人手机号并在申请记录持久化。这是走法人路线的唯一新增字段（法人姓名、证件号、证件有效期、证件居住地址已由现有进件采集）。不得复用联系人手机号冒充法人手机号。 - [ ] 发起前校验前置条件：商户必须已成功入驻微信、且所需能力已开通；材料不齐时给出具体缺项而不是提交后被驳回。材料上传复用现有图片上传通道，文件类型按官方要求。 .scratch/merchant-wechat-onboarding/ticket-plan.md
@@ -27,10 +27,19 @@ 每个独立 Issue 包含自身验收条件及共同约束。自动化使用模拟汇付响应，不创建真实商户；真实联调失败先核对原申请，不反复新进件制造控台记录。 ### 执行顺序 1. **04 第一步**：清理进度服务的单商户硬编码（删除 `RECOVERY_HUIFU_ID` 恢复路径，进度按申请单通用）。纯清理、体量小，做完两张票都落在干净地基上。 2. **04 其余部分**：新建实名申请能力、法人手机号字段、授权状态闭环、收款就绪纳入实名。 3. **03**：把新商户接入已通用化的分阶段视图，提供“下一步”推进与微信业务开通的商户手动入口。 顺序依据：03 的第三个阶段就是微信实名，先落地 04 才能让 03 的阶段推进接在真能力上；而 04 必须先清理再往上加实名阶段，否则它的实名进度要建在即将删除的代码上。 ### 两张票的冲突面 - **进度服务**：03 要按申请单通用地重做分阶段进度并去掉只服务一张商户的恢复路径，04 要往里加实名阶段。04 先做时不要为实名加深对现有硬编码的依赖，否则 03 要返工。 - **商户端进件表单**：04 加法人手机号，03 加行业与材料校验。谁先落地谁先改，另一张做增量。 - **进度服务**：已指派给 04（见执行顺序第 1 步）；03 只接入已通用化的视图，不重复改造。 - **商户端进件表单**：04 加法人手机号，03 加行业与材料校验。04 先落地，03 在此基础上做增量。 - **收款就绪门槛**：实现在 04（`MerchantPaymentReadinessService` 补上微信业务开通与实名/授权）；03 只做验收核对，不重复实现。 - **共享文件**：`application.yml`、`AdminBusinessService.java`、`CONTEXT.md` 等只做自己范围内的增量小改，不顺手整理。 ## 确认记录
