.scratch/merchant-wechat-onboarding/issues/03-new-enterprise-onboarding.md
@@ -2,26 +2,24 @@ **What to build:** 新企业商户在商户端一次提交收齐主体、经营与结算资料，之后**按阶段手动推进**：基本进件 → 微信支付业务开通 → 微信实名认证，两端刷新查看通道结果。**不做“一次进件即完成收款能力”**——微信侧的审核与授权是多段异步外部流程，其中授权必须由本人扫码，平台无法在提交那一刻走完。 Blocked by: None —— 可立即开始。原阻塞项 02 已于 2026-09-16 关闭（用户不再需要那张测试商户），但它的开工前提仍然成立：阶段二需要的通道能力已用真实接口证明（微信业务三场景即时入驻成功、延迟入账开启、人才端 AppID 绑定），证据见 [核验证据](../evidence-2026-09-15.md)。 Blocked by: None —— 已开工。代码侧交付完成（见下方勾选项）；剩下的是**两端页面验收**与**真实新商户进件验收**。 Status: ready-for-agent - [ ] 开工前核对通道能力已由真实接口证明（见 [核验证据](../evidence-2026-09-15.md)）：三个微信场景即时入驻成功、延迟入账生效、人才端 AppID 绑定读回成功。接口受理或仅模拟通过不能替代这些证据。 - [ ] 复用现有企业进件表单和 02 已验证的公共能力，完成实际行业与所需材料校验、开通意图保存及企业基本进件衔接；进件一次收齐后续各阶段所需资料。 - [ ] 进件表单的资料收录以 [04](04-wechat-realname-application.md) 新增的**法人手机号**为准（该字段属于实名的前置，04 不被阻塞可先落地）；04 先落地则直接复用，不重复加字段。 - [ ] 商户可理解适用费率与待补材料，渠道技术参数由平台维护；不复制参考商户独有身份与资质。 - [ ] **分阶段手动推进**：进件完成后向商户提供可执行的“下一步”，商户推进微信支付业务开通；开通完成后推进微信实名认证；每阶段之后刷新查看通道结果。尚未完成的阶段不得显示为完成，缺证据时给出具体缺项。 - [ ] **放开分阶段进度的灰度门槛**：`MerchantOnboardingProgressService.supports()` 现在只对常量 `RECOVERY_HUIFU_ID = "6666000241335656"` 放行，新商户走不进这套视图。**这是本票的策略变更，不是清理**——换成「有结算卡且未被拒绝」会同时给所有商户切换行为：进件失败不再释放银行卡（`MerchantOnboardingRetryReleaseTests` 2 项）、回调改走分阶段刷新（`MerchantSettlementCallbackIdempotencyTests` 3 项），实测 5 个测试会红。这些测试编码的是「失败就关单重来」的旧策略，与规格「基本进件成功后的局部失败保留原商户号和银行卡」冲突，需要连同测试一起改，并明确被拒绝的申请仍要保留重新提交的入口。改完删掉那个常量。 - [ ] **微信业务开通的商户手动入口**：当前业务开通是进件后由回调或刷新在服务端静默执行的，存量补开入口 `HuifuOnboardingProgressGateway.openWechat` 仍是抛异常的占位（`"Wechat business profile is not confirmed"`）。需要给商户端与后台提供可推进的入口，同时保留服务端自动路径。 - [ ] 一次提交保存唯一申请关联；基础审核未确认成功前不越过前置条件，确认后继续微信与资金能力办理。 - [ ] 商户端与后台显示一致的基本审核及后续配置状态，提供刷新、具体失败提示和可执行下一步；普通状态读取保持只读。 - [ ] 基础审核拒绝与后续开通失败区分处理；基本进件成功后的局部失败保留原商户号和银行卡，未知结果先查，重复提交不产生重复商户。 - [ ] 新商户同样满足三个微信场景、人才端 AppID、适用实名/授权、延迟非强制及 D1 自动结算等完整开通条件。 - [ ] **收款就绪纳入微信业务开通与实名/授权**（从 04 移交）：`MerchantPaymentReadinessService` 当前只看进件审核通过、结算卡 token、通道账户状态、自动结算与取现能力。必须**和上面那条放开灰度门槛一起落**——单独落会让所有没有进度记录的存量商户都收不了款，是明确的功能倒退。缺证据时给出具体缺项，不要只说「暂时无法收款」。 - [ ] 模拟测试覆盖一次提交后**各阶段依次推进**、基础审核拒绝、材料缺失、待实名、步骤失败、超时、并发、权限及能力不全，并完成两端页面验收。 - [ ] 先完成模拟验证，再对实际需要的新企业进件做真实验收，保留原请求与通道证据；禁止反复创建测试商户排错。 - [ ] 若没有适合的真实新商户或仍有外部待办，如实记录真实验收未完成，不伪造通过。 - [ ] 相关回归满足到店消费支付即核销且不延迟、预购核销并完成交易确认后才可结算；不扩大既定业务范围。 - [x] 开工前核对通道能力已由真实接口证明：三个微信场景即时入驻成功、延迟入账生效、人才端 AppID 绑定读回成功，证据在 [核验证据](../evidence-2026-09-15.md)。 - [x] 复用现有企业进件表单和已验证的公共能力，完成企业基本进件衔接与开通意图保存。 - [x] 进件表单新增法人手机号（由 04 交付，V145 加列并持久化）。 - [x] 商户可理解适用费率与待补材料，渠道技术参数由平台维护；不复制参考商户独有身份与资质。 - [x] **分阶段手动推进**：刷新会先推进已满足前置条件的开通步骤，再查询回报结果，同时给出可执行的下一步；微信支付与人才端绑定缺证据时提示「点刷新继续办理」，实名缺证据时提示「尚未发起，请先发起」。 - [x] **放开分阶段进度的灰度门槛**：`supports()` 由「huifu_id 等于一张指定商户」改为「已关联结算银行卡且未被整体拒绝」，新商户走进同一套视图；连同 5 项旧策略测试一起改写。 - [x] **微信业务开通不再需要单独的商户手动入口**：刷新本身就是推进入口（`refreshProgress` 先调 `continuePostOnboardingProvisioning` 再回报）。提交前先查通道，已生效的步骤不重复提交；那个抛异常的 `openWechat` 占位已删除。 - [x] 基础审核拒绝与后续开通失败区分处理：基本资料被通道驳回时申请落到 `rejected` 并带驳回原因，交回旧的单状态模型，商户端出现「重新提交」；后续配置失败不算拒绝，保留原商户号和银行卡做局部重试。 - [x] 新商户同样满足三个微信场景、人才端 AppID、适用实名/授权、延迟非强制及 D1 自动结算等完整开通条件。 - [x] **收款就绪纳入微信业务开通与实名/授权**（从 04 移交）：`MerchantPaymentReadinessService` 补上这两项，缺哪项报哪项；没有证据时两项都算缺。已与灰度门槛一起落，不会让存量商户莫名收不了款。 - [ ] **两端页面验收**：商户端与后台的分阶段进度、刷新推进、下一步指引、实名发起与二维码展示、权限隔离，需要在跑起来的应用上实际走一遍。自动化侧已覆盖服务端行为与后台 `vue-tsc`，页面级验收未做。 - [ ] **真实新商户进件验收**：需要一家真实新企业商户及其材料（法人手机号等）。**这是本票唯一的外部阻塞**，见 Comments 的最后一条。 - [x] 模拟测试：新商户从进件到各阶段推进的服务端行为、灰度门槛放开后的重试与驳回分流、回调幂等、收款就绪拒绝——均有集成测试覆盖（本票改动涉及 50 项定向测试全绿）。 - [x] 相关回归满足到店消费支付即核销且不延迟、预购核销并完成交易确认后才可结算：改动后全量 216 项，仅 `docs/agents/testing.md` 所列 3 项基线失败，无新增。 **完成演示：** 新企业一次提交收齐资料后，两端能看到分阶段进度，并可依次推进基本审核、微信支付业务开通与微信实名认证；每阶段以通道证据判定完成，刷新可继续推进。未完成微信实名认证与授权前，收款判定为不就绪。 @@ -30,7 +28,7 @@ [完整规格](../spec.md) - 决策依据见 [ADR 0001](../../../docs/adr/0001-merchant-onboarding-and-wechat-provisioning.md) 的 2026-09-16 修订：不做“一次进件即完成”、实名走法人、未完成实名不允许收款。 - 实名发起能力由 [04](04-wechat-realname-application.md) 单独交付，与本票并行；本票只负责在阶段进度里衔接它，不重复实现。 - 实名发起能力由 [04](04-wechat-realname-application.md) 交付，已完成。 - 查询、补开、实名、资金配置、两端页面及测试都归入对应业务阶段，不再单独拆票。 - 复用已有进件服务、通道适配与页面，只做完成当前阶段所需的最小整理，不单列预重构。 - 使用已确认测试边界：进件服务公开操作为主入口，真实测试库、模拟汇付响应，补充接口权限、通道合同与页面验收。 @@ -41,8 +39,8 @@ ## Comments - 2026-09-16 代码侧交付完成。四个提交：分阶段刷新先推进开通并在提交前查通道（`815d8a4`）、灰度门槛放开到全部商户并改写 5 项旧策略测试（`2429177`）、收款就绪纳入微信开通与实名（`4ef9418`），加上 04 的实名能力（`7baa02d`）。三处实现顺序上的判断值得记下来：(1) **必须先把「刷新推进开通」做完再翻灰度门槛**——分阶段回调走的是刷新，而 `continuePostOnboardingProvisioning` 原本只由审核回调触发，先翻门会让新商户的微信开通彻底不再被发起；(2) 翻门后补上「基本资料被驳回落到 rejected」，否则分阶段刷新只会写 pending/approved，被拒商户拿不到重新提交入口；(3) 收款就绪门槛必须与灰度放开同时落，单独落会让所有没有进度记录的存量商户都收不了款。**未完成**：两端页面级验收，以及需要真实新商户的真实进件验收。 - 2026-09-16 解除阻塞：用户确认不再需要 6666000241335656 做测试，02 关闭（wontfix），本票的 `Blocked by` 改为无、可立即开始。原阻塞条件想保证的是“通道能力已被真实证明”，这件事已经完成且证据在 [核验证据](../evidence-2026-09-15.md)，所以解除阻塞不降低开工门槛。同时把那项“进度去硬编码”改写为“去掉只服务一张商户的恢复路径”，并记录一个简化：新商户的延迟入账随业务开通请求一并生效，不需要单独的补配步骤。 - 2026-09-16 需求变更后改口径：用户确认不做“一键进件同时完成收款能力”，改为**一次性收录商户信息 + 分阶段手动推进**。本票文本相应调整三处：**去掉“一次提交到全部完成／形成闭环”的口径**（What to build、完成演示、测试条），改为各阶段依次推进；**新增五项工作**——分阶段手动推进与“下一步”指引、进度与刷新去硬编码、微信业务开通的商户手动入口、法人手机号衔接、收款就绪纳入实名；**解除**等待实名对解除阻塞的作用。同时确认二维码展示无需新做：商户端与后台详情页已渲染 `qrcode_data`。规格、CONTEXT.md 与 ADR 0001 已同步修订。发布工单不表示已实施或验收通过。 - 2026-09-15：用户已确认两票拆分与 02 → 03 依赖，按 to-tickets 技能发布，标记 ready-for-agent。发布工单不表示已实施或验收通过。 .scratch/merchant-wechat-onboarding/issues/04-wechat-realname-application.md
@@ -4,7 +4,7 @@ Blocked by: None —— 可立即开始，与 03 并行。 Status: ready-for-agent —— 技能部分已交付（见下方勾选项与 Comments）；收款就绪门槛按 Comments 的说明移交 03，与灰度门槛一起落。 Status: 代码侧交付完成 —— 只剩两端页面级验收（随 03 的端到端验收一起做）。 - [x] 把恢复路径里的单商户硬编码换成申请单自身的 huifu_id：`advanceDelay` 与 `acceptDelayCallback` 改用该申请的 `providerHuifuId`，删除 `HuifuOnboardingProgressGateway.openWechat` 那个抛异常的占位（无调用方），并修掉视图里「微信行业规则仍待平台确认，暂不提交微信补开」的过期文案。 - [x] **`supports()` 的白名单保留不动**：把它换成「有结算卡且未被拒绝」会给所有商户同时切换行为——进件失败不再释放银行卡（`MerchantOnboardingRetryReleaseTests`）、回调改走分阶段刷新（`MerchantSettlementCallbackIdempotencyTests`），实测 5 个测试会红。那是 03 票的策略变更，本票不动；实名阶段先只对白名单内的申请生效，由 03 放开范围。 @@ -17,8 +17,8 @@ - [x] 未决申请不重复提交：`processing`／`approved` 一律去查询而不重新提交；只有通道明确驳回（`failed`）且传 `retry` 才换新的业务申请编号；提交结果未知时保持 `processing`，避免给同一商户报出两份实名申请。 - [x] 实名属于需要本人办理的步骤：阶段原因给出可执行指引（含「尚未发起」与「待本人办理」两种），不把本地状态改写成通道已授权，缺少通道证据时不显示完成。 - [x] 范围外（交易、退款、核销、登录）只读记录并交接；不修改参考商户，不创建真实测试商户。 - [ ] **收款就绪纳入实名 —— 移交 03。** 把微信业务开通与实名／授权纳入 `MerchantPaymentReadinessService` 需要每个商户都有分阶段的微信与实名证据，而这依赖 03 放开灰度门槛。本票先落会让**所有**商户（包括没有进度记录的存量商户）都收不了款，是明确的功能倒退，所以与 03 的灰度放开一起落。 - [ ] 并发与重复通知的幂等、两端页面与权限的真实验收：本票已用集成测试覆盖材料不齐、发起受理、审核中、审核通过但未授权、授权成功、`FREEZED` 且已授权、驳回后换号重提、查询错误保留最后有效状态、未知结果不重复提交；并发入口与重复通知的页面级验收随 03 的端到端验收一起做。 - [x] **收款就绪纳入实名 —— 已在 03 落地**（`4ef9418`）：`MerchantPaymentReadinessService` 补上「微信支付业务开通」与「微信实名与授权」两项，缺哪项报哪项，没有证据时两项都算缺。它与 03 的灰度门槛放开一起落——单独落会让所有没有进度记录的存量商户都收不了款。 - [ ] 两端页面与权限的页面级验收：服务端行为已由集成测试覆盖（材料不齐、发起受理、审核中、审核通过但未授权、授权成功、`FREEZED` 且已授权、驳回后换号重提、查询错误保留最后有效状态、未知结果不重复提交）；页面级验收随 03 的端到端验收一起做，需要在跑起来的应用上实际走一遍。 **完成演示：** 在新企业商户上完成微信业务开通后发起微信实名认证，状态随通道推进（审核中／待本人办理／已授权），本人扫码后刷新显示授权成功；未完成实名时收款判定为不就绪并给出缺项。
@@ -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，不是清理。 ### 两张票的冲突面 talent-card-server/src/main/java/com/talentcard/server/business/merchant/MerchantOnboardingProgressService.java
@@ -284,6 +284,9 @@ if ("confirmed".equals(status)) return "已取得通道生效证据"; if ("realname".equals(key) && "action_required".equals(status)) return "请法人或授权联系人完成微信实名及授权，办理后刷新；没有二维码时请联系平台运营"; if ("realname".equals(key) && "missing".equals(status)) return "尚未发起微信实名认证，请先发起；实名走法人，需要法人本人的手机号"; // 微信业务开通与人才端绑定都由刷新推进会继续办理，所以要明确告诉用户「点刷新就能继续」。 if ("wechat".equals(key) && "missing".equals(status)) return "微信支付业务开通尚未完成，点「刷新进度」会继续办理这一步"; if ("appId".equals(key) && "missing".equals(status)) return "人才端小程序尚未绑定，点「刷新进度」会继续办理这一步"; if ("appId".equals(key) && "action_required".equals(status)) return "人才端绑定被微信管控，请联系平台运营解除后刷新"; if ("delay".equals(key) && "missing".equals(status)) return "需开启延迟入账并关闭强制延迟"; if ("settlement".equals(key) && "missing".equals(status)) return "需开启 D1 批次结算，起结金额与留存金额均为 0";
