From 3a024caa497b8923635c02e0c8c0df07f2918f81 Mon Sep 17 00:00:00 2001 From: yeg <1347747024@qq.com> Date: 星期三, 16 九月 2026 00:53:12 +0800 Subject: [PATCH] docs(merchant): 03/04 代码侧交付完成，补可执行的阶段指引 --- .scratch/merchant-wechat-onboarding/ticket-plan.md | 21 ++++++++++++++------- 1 files changed, 14 insertions(+), 7 deletions(-) diff --git a/.scratch/merchant-wechat-onboarding/ticket-plan.md b/.scratch/merchant-wechat-onboarding/ticket-plan.md index f6eb5f6..6ddfc8e 100644 --- a/.scratch/merchant-wechat-onboarding/ticket-plan.md +++ b/.scratch/merchant-wechat-onboarding/ticket-plan.md @@ -1,6 +1,6 @@ # 企业商户进件与微信开通：已确认任务拆分 -状态：用户已确认。2026-09-16 因需求变更（不做一键进件、实名走法人、未完成实名不允许收款）调整为三张工单，同日因用户不再需要测试商户 6666000241335656 关闭其中 02，现为两张并行工单。 +状态：用户已确认。2026-09-16 因需求变更（不做一键进件、实名走法人、未完成实名不允许收款）调整为三张工单，同日因用户不再需要测试商户 6666000241335656 关闭其中 02。03 与 04 的**代码侧已交付**（见「执行顺序」的提交号），剩下两端页面级验收与真实新商户进件验收。 日期：2026-09-15 首次发布；2026-09-16 修订两次。 依据：[完整规格](spec.md) 与 [ADR 0001](../../docs/adr/0001-merchant-onboarding-and-wechat-provisioning.md) 的 2026-09-16 修订。 @@ -10,8 +10,8 @@ | 编号 | 任务 | Blocked by | Status | | --- | --- | --- | --- | | 02 | [完成指定存量商户微信与资金能力开通](issues/02-existing-merchant-wechat-activation.md) | — | wontfix（2026-09-16 关闭，产出已合入，证据保留） | -| 03 | [新企业商户进件与分阶段开通微信收款能力](issues/03-new-enterprise-onboarding.md) | 无，可立即开始 | ready-for-agent | -| 04 | [微信实名认证发起与授权闭环](issues/04-wechat-realname-application.md) | 无，与 03 并行 | ready-for-agent | +| 03 | [新企业商户进件与分阶段开通微信收款能力](issues/03-new-enterprise-onboarding.md) | 无，可立即开始 | 代码侧已交付；剩页面级与真实新商户验收 | +| 04 | [微信实名认证发起与授权闭环](issues/04-wechat-realname-application.md) | 无，与 03 并行 | 代码侧已交付；剩页面级验收 | ## 执行规则 @@ -27,14 +27,21 @@ 每个独立 Issue 包含自身验收条件及共同约束。自动化使用模拟汇付响应，不创建真实商户；真实联调失败先核对原申请，不反复新进件制造控台记录。 -### 执行顺序 +### 执行顺序（代码侧已完成） -1. **04 第一步（已完成）**：把恢复路径里的单商户硬编码换成申请单自身的 huifu_id，删除 `HuifuOnboardingProgressGateway.openWechat` 占位与视图里的过期文案。 -2. **04 其余部分**：新建实名申请能力、法人手机号字段、授权状态闭环、收款就绪纳入实名。 -3. **03**：放开分阶段进度的灰度门槛（连同 5 个测试的策略改写），提供“下一步”推进与微信业务开通的商户手动入口。 +1. **04 第一步**（`87eca64`）：恢复路径改用申请单自身的 huifu_id，删除 `HuifuOnboardingProgressGateway.openWechat` 占位与视图里的过期文案。 +2. **04 其余部分**（`7baa02d`）：新建实名申请能力、法人手机号字段、授权状态闭环。 +3. **03**：分阶段刷新先推进开通并在提交前查通道（`815d8a4`）→ 放开灰度门槛并改写 5 项旧策略测试（`2429177`）→ 收款就绪纳入微信开通与实名（`4ef9418`）。 顺序依据：03 的第三个阶段就是微信实名，先落地 04 才能让 03 的阶段推进接在真能力上。 +**实现中的三处顺序判断**（都不在原计划里，都是动手才发现的）： +- **先补「刷新推进开通」再翻灰度门槛**：分阶段申请的回调走的是刷新，而 `continuePostOnboardingProvisioning` 原本只由进件审核回调触发；先翻门会让新商户的微信开通彻底不再被发起。 +- **翻门之后补「基本资料被驳回落到 rejected」**：分阶段刷新原本只会写 pending/approved，被拒商户拿不到重新提交入口。 +- **收款就绪门槛与灰度放开同时落**：单独落会让所有没有进度记录的存量商户都收不了款。 + +**剩下两件**：两端页面级验收；需要真实新商户及其材料的真实进件验收。 + **一处修正**：原先把「去掉 `RECOVERY_HUIFU_ID`、进度按申请单通用」算作 04 的清理，动手后发现站不住。`supports()` 不只是白名单，它还是「分阶段模型 vs 旧单状态模型」的路由开关：换成「有结算卡且未被拒绝」会同时给**所有**商户切换行为——进件失败不再释放银行卡（`MerchantOnboardingRetryReleaseTests` 2 项）、回调改走分阶段刷新（`MerchantSettlementCallbackIdempotencyTests` 3 项），实测 5 个测试会红。那是策略变更，归 03，不是清理。 ### 两张票的冲突面 -- Gitblit v1.7.1