.scratch/merchant-wechat-onboarding/issues/02-existing-merchant-wechat-activation.md
@@ -4,7 +4,7 @@ Blocked by: None — can start immediately Status: ready-for-agent Status: wontfix —— 2026-09-16 用户确认不再需要该商户做测试，本票关闭；已交付的代码与证据见下方 Comments，未删除。 - [x] 先核实官方查询、补开、配置及实名接口和状态语义，只读核对目标商户原申请与实际配置，明确缺项；不能预设卡住原因。 - [ ] 商户端和后台均能刷新尚未整体通过的申请，展示一致的分阶段进度、最后同步时间、具体原因与下一步；权限与敏感信息展示符合规格。 @@ -35,6 +35,8 @@ ## Comments - 2026-09-16 关闭（wontfix）：用户确认不再需要 6666000241335656 这个商户做测试，本票剩下的验收工作（两端页面的真实验收、未决申请后续、回调与幂等真实验收）失去对象，不再执行。**本票的产出不因此作废**：(1) 三个真实缺陷修复已作为 `c18b9fa` 提交并合入（`media_mer_common_flag` 层级、`use_chains_flag=3` 不成立、`90000000` 被当成失败）；(2) 阶段二需要的通道能力已用真实接口证明——微信业务三场景 `wx_conf_status=S` 即时入驻成功、`delay_flag` 由 N 变 Y、人才端 AppID 读回绑定成功；(3) 只读核验证据与官方接口原文已作为 `96c32c2` 归档。因此关闭本票不损失任何东西，03 的开工前提（通道能力已验证）依然成立。该商户保持“待实名”，按规格「收款就绪的前提」在实名完成前不能收款；用户已确认不需要它。**遗留待决**：只服务这张商户的恢复路径（`MerchantOnboardingProgressService.RECOVERY_HUIFU_ID`、`HuifuOnboardingProgressGateway.configureDelay` 与其 `advanceDelay` 阶段、`openWechat` 抛异常的占位）现已无使用对象，是删除还是保留为通用能力需要用户决定。 - 2026-09-16 范围调整：用户确认“实名走法人”与“未完成实名前不允许商户收款”后，本票的**实名与授权条款移交给 [04](04-wechat-realname-application.md)**，验收范围收回到已取得通道证据的部分（微信业务三场景开通、人才端 AppID 绑定、延迟入账开启、D1 结算）。同时解除“待实名”对 03 的阻塞：原阶段切换条件要求指定商户实名/授权已确认成功，而实名发起能力当前为零，构成 02 ⇄ 03 死锁；规格的阶段切换条件已同步修订。指定商户保持“待实名”待办，由 04 建成能力后办理，按规格「收款就绪的前提」在实名完成前不能收款。本票的真实证据不受影响，保留原样。 - 2026-09-15 真实补开与能力落地：用户确认该商户是测试商户、授权「直接用 756 开」并把延迟入账一并打开，已完成并读回验证。微信业务补开受理（`apply_no=2026091530554624`，`90000000 审核中`），申请单状态查询显示**场景 4/5/12 全部 `wx_conf_status=S`、原因「入驻成功」**，各自拿到微信子商户号 `W15737921333057628112`（`sub_mer_name` 即商户注册名）；商户详情 `qry_wx_conf_list` 三场景 `fee_rate=0.70`、`fee_charge_type=1`（实收）、`out_fee_flag=2`（内扣），渠道 `00016904`；**`delay_flag` 由 N 变 Y**、`forced_delay_flag=N`；D1／P0／起结 0／留存 0 未变；结算卡仍是原卡（尾号 7957），商户号未重建。人才端 AppID 已绑定：`v2.merchant.busi.config.query` 读回 `wx_applet_app_id=wxcfee477acb54d179`、`config_type=1`、无管控。实名状态由补开前的「AT入驻信息池信息不存在」变为 `APPLYMENT_STATE_NOAPPLY` + `authorize_stat=0`，即微信已入驻、**实名与授权尚未发起**（需商户本人扫码，人工步骤）。过程中修掉三个真实缺陷：`media_mer_common_flag` 被错放在顶层（实为 `online_media_info_list` 的元素字段，通道报「不能为空,或格式非法」）；`use_chains_flag=3` 不成立（上级是渠道商、无商户级微信配置，通道报「复用交易信息，上级商户号为空」），默认值改为留空；`90000000`（审核中）被业务开通网关当成失败，会把一次成功受理记成 `business_open_status=failed`。相关测试通过（`HuifuBusinessOpenRequiredFieldsTests` 6、`HuifuBusinessOpenResultTests` 2、`HuifuOnboardingMerchantLevelTests` 4、`MerchantExistingOnboardingTests` 17），全量 198 项仅剩 `docs/agents/testing.md` 记录的三项基线失败。详细记录见 [核验证据](../evidence-2026-09-15.md)。仍缺：实名与授权、两端页面的真实验收（本地申请 449 仍 `status=pending`、微信配置与业务开通仍 `not_started`，需走一次刷新）、未决申请的后续查询或回调、回调与幂等真实验收。本票未完成，03 继续阻塞。 .scratch/merchant-wechat-onboarding/issues/03-new-enterprise-onboarding.md
@@ -1,17 +1,17 @@ # 03 — 新企业商户进件与分阶段开通微信收款能力 **What to build:** 02 真实验收通过后，新企业商户在商户端一次提交收齐主体、经营与结算资料，之后**按阶段手动推进**：基本进件 → 微信支付业务开通 → 微信实名认证，两端刷新查看通道结果。**不做“一次进件即完成收款能力”**——微信侧的审核与授权是多段异步外部流程，其中授权必须由本人扫码，平台无法在提交那一刻走完。 **What to build:** 新企业商户在商户端一次提交收齐主体、经营与结算资料，之后**按阶段手动推进**：基本进件 → 微信支付业务开通 → 微信实名认证，两端刷新查看通道结果。**不做“一次进件即完成收款能力”**——微信侧的审核与授权是多段异步外部流程，其中授权必须由本人扫码，平台无法在提交那一刻走完。 Blocked by: 02 — 完成指定存量商户微信与资金能力开通。**02 的“待实名”不阻塞本票**（原阶段切换条件已修订，见规格与 ADR 0001 的 2026-09-16 修订）。 Blocked by: None —— 可立即开始。原阻塞项 02 已于 2026-09-16 关闭（用户不再需要那张测试商户），但它的开工前提仍然成立：阶段二需要的通道能力已用真实接口证明（微信业务三场景即时入驻成功、延迟入账开启、人才端 AppID 绑定），证据见 [核验证据](../evidence-2026-09-15.md)。 Status: ready-for-agent - [ ] 开始本票实现及真实新进件联调之前，核对 02 的真实成功证据；接口受理或仅模拟通过不能解除阻塞。等待实名不再作为解除条件。 - [ ] 开工前核对通道能力已由真实接口证明（见 [核验证据](../evidence-2026-09-15.md)）：三个微信场景即时入驻成功、延迟入账生效、人才端 AppID 绑定读回成功。接口受理或仅模拟通过不能替代这些证据。 - [ ] 复用现有企业进件表单和 02 已验证的公共能力，完成实际行业与所需材料校验、开通意图保存及企业基本进件衔接；进件一次收齐后续各阶段所需资料。 - [ ] 进件表单的资料收录以 [04](04-wechat-realname-application.md) 新增的**法人手机号**为准（该字段属于实名的前置，04 不被阻塞可先落地）；04 先落地则直接复用，不重复加字段。 - [ ] 商户可理解适用费率与待补材料，渠道技术参数由平台维护；不复制参考商户独有身份与资质。 - [ ] **分阶段手动推进**：进件完成后向商户提供可执行的“下一步”，商户推进微信支付业务开通；开通完成后推进微信实名认证；每阶段之后刷新查看通道结果。尚未完成的阶段不得显示为完成，缺证据时给出具体缺项。 - [ ] **进度与刷新去硬编码**：现有分阶段进度与刷新只对常量 `RECOVERY_HUIFU_ID = "6666000241335656"` 生效（`MerchantOnboardingProgressService.supports()`）。必须改成按申请单通用，让新商户走进同一套分阶段视图；`merchant_onboarding_progress` 已按 `application_id` 建表，结构上支持。 - [ ] **进度与刷新去掉只服务一张商户的恢复路径**：现有分阶段进度与刷新只对常量 `RECOVERY_HUIFU_ID = "6666000241335656"` 生效（`MerchantOnboardingProgressService.supports()`），随 02 关闭已无使用对象，而新商户需要同一套分阶段视图。按申请单通用地重做（`merchant_onboarding_progress` 已按 `application_id` 建表，结构上支持）；同时决定 `configureDelay`／`advanceDelay` 阶段与 `openWechat` 抛异常的占位是删除还是保留为通用能力。注意**新商户的延迟入账随业务开通请求一并生效**（`delay_flag=Y`／`forced_delay_flag=N` 已在请求里），不需要单独的补配步骤。 - [ ] **微信业务开通的商户手动入口**：当前业务开通是进件后由回调或刷新在服务端静默执行的，存量补开入口 `HuifuOnboardingProgressGateway.openWechat` 仍是抛异常的占位（`"Wechat business profile is not confirmed"`）。需要给商户端与后台提供可推进的入口，同时保留服务端自动路径。 - [ ] 一次提交保存唯一申请关联；基础审核未确认成功前不越过前置条件，确认后继续微信与资金能力办理。 - [ ] 商户端与后台显示一致的基本审核及后续配置状态，提供刷新、具体失败提示和可执行下一步；普通状态读取保持只读。 @@ -40,6 +40,8 @@ ## Comments - 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
@@ -1,8 +1,8 @@ # 04 — 微信实名认证发起与授权闭环 **What to build:** 让平台能发起微信实名认证申请并闭环授权状态：进件时一次收齐法人手机号，基础进件与微信业务开通到位后由两端入口发起实名，展示授权二维码供本人扫描，并把实名与授权纳入收款就绪判定。本票不依赖 02 的真实证据，与 03 并行推进。 **What to build:** 让平台能发起微信实名认证申请并闭环授权状态：进件时一次收齐法人手机号，基础进件与微信业务开通到位后由两端入口发起实名，展示授权二维码供本人扫描，并把实名与授权纳入收款就绪判定。它是新商户收款链路的第三个阶段（进件 → 微信业务开通 → 微信实名），与 03 并行推进。 Blocked by: None — 可立即开始（它正是解开 02 ⇄ 03 死锁的那一票）。 Blocked by: None —— 可立即开始，与 03 并行。 Status: ready-for-agent @@ -19,7 +19,7 @@ - [ ] 实名属于需要本人办理的步骤，提供可执行指引；不得把本地状态改写成通道已授权，也不得在缺少通道证据时显示完成。 - [ ] 范围外（交易、退款、核销、登录）只读记录并交接；不修改参考商户，不创建真实测试商户。 **完成演示：** 在商户端或后台对指定存量商户发起微信实名认证，状态随通道推进（审核中／待本人办理／已授权），本人扫码后刷新显示授权成功；未完成实名时收款判定为不就绪并给出缺项。 **完成演示：** 在新企业商户上完成微信业务开通后发起微信实名认证，状态随通道推进（审核中／待本人办理／已授权），本人扫码后刷新显示授权成功；未完成实名时收款判定为不就绪并给出缺项。 ## 规格与共同约束 @@ -34,4 +34,4 @@ ## Comments - 2026-09-16：用户确认“实名走法人”“未完成实名前不允许商户收款”两项决策后发布。本票从 03 的实名条款拆出**并解除其与 02 的依赖**：02 的阶段切换条件原本要求指定商户实名/授权已确认成功，而实名发起能力当前为零，形成“阶段二要等阶段一、阶段一又要等阶段二才建的能力”的死锁。规格中的阶段切换条件已同步修订，“等待实名”不再阻塞阶段切换。发布工单不表示已实施或验收通过。 - 2026-09-16：用户确认“实名走法人”“未完成实名前不允许商户收款”两项决策后发布。它是新商户收款链路的第三个阶段，与 03 并行、不被任何票阻塞。发布时它同时承担解开 02 ⇄ 03 死锁的作用（02 的阶段切换条件原本要求指定商户实名/授权已确认成功，而实名发起能力当前为零）；**当日该商户已随 02 关闭而不再需要测试**，死锁一并消失，本票的成立理由回到“任何商户要能收款都需要实名”这一条。发布工单不表示已实施或验收通过。 .scratch/merchant-wechat-onboarding/spec.md
@@ -1,9 +1,11 @@ # 企业商户进件、微信支付与延迟入账开通闭环 Status: ready-for-agent 更新日期：2026-09-15 更新日期：2026-09-16 规格来源：本会话已确认的业务决策及只读代码、汇付文档和控台核查。 测试边界：用户已确认以进件服务为主入口、真实测试库与模拟汇付响应，并补充接口权限和页面验收。 **2026-09-16 修订（影响全文）：** 用户确认不再需要 6666000241335656 做测试，工单 02（存量商户恢复）关闭。因此下文中“先验收指定存量商户、再开展新商户流程”的两阶段框架、阶段切换条件与相关用户故事**整体作废**：新企业商户的分阶段流程（03）与微信实名能力（04）两票并行、互不阻塞。指定存量商户只保留为**通道能力的验证来源**——微信业务三场景即时入驻成功、延迟入账生效、人才端 AppID 绑定成功均已用真实接口证明并归档在 [核验证据](evidence-2026-09-15.md)。它的“待实名”状态按下方「收款就绪的前提」处理，不再是任何一票的验收条件或阻塞项。 ## Problem Statement @@ -95,11 +97,9 @@ - **返回契约**：两端返回一致的分阶段进度、最后成功同步时间、当前同步错误、可执行操作与失败原因；保留已有消费者所需的兼容信息。最终端点名与字段命名由实现时沿用仓库风格确定。 - **权限与信息展示**：商户入口按登录商户和门店权限定位申请，不信任前端传入的任意汇付商户号；后台沿用既有运营权限。对商户展示可处理的业务提示，对运营提供必要的脱敏诊断信息。 - **实名/签约**：需要商户本人完成的实名、授权或签署通过通道提供的指引办理，不能将本地状态改写为通道已授权。**“接口能否发起实名及所需材料”的核查已完成（2026-09-15）**：平台当前没有任何实名发起能力，全仓只有 `v2.merchant.busi.realname.query` 查询，实名申请接口 `v2.merchant.busi.realname` 必须新建；走法人只需法人姓名、证件号、证件有效期与证件居住地址（进件已有）加**法人手机号**（进件新增）；实名分两个阶段，`APPLYMENT_STATE_PASSED` 只表示申请单审核通过，还要 `authorize_stat=1` 才算授权完成，而授权由本人扫描通道回传的小程序码完成，平台只能展示该二维码并查询状态。 - **存量恢复**：仅恢复 6666000241335656。先只读核对本地关联、汇付审核和实际配置，再复用原商户号补齐缺失能力。保留已成功步骤与银行卡，不批量修复或重新打开其他小微商户。 - **阶段一优先且阻塞阶段二**：先完成指定存量商户微信开通所需的查询、补开、实名/授权衔接及必要能力核验，并取得汇付侧成功证据；阶段一只实现和验证这些工作所需的公共能力，不先扩展新商户完整进件流程，不调用真实新商户进件接口。 - **阶段切换条件**：指定商户的微信业务与人才端 AppID 已确认成功，并核实延迟入账及自动结算满足本规格。受理成功、处理中、超时或仅本地成功都不能通过该条件。记录真实结果和时间后，再进入新增企业商户“进件 + 微信业务开通”流程的实现与联调。 - **“等待实名”不是阶段切换的阻塞项**：实名需要平台先具备发起能力，而该能力当前为零。把它列为阶段切换条件会造成死锁——阶段二要等阶段一完成，阶段一又要在阶段二里才建起来。**实名发起能力单独立票、与阶段二并行推进**，指定商户的实名在其建成后办理；在此之前指定商户保留“待实名”待办，不影响阶段二开工。 - **真实测试数据约束**：普通自动化测试全部模拟汇付，不创建真实商户。阶段二也不能把反复真实新进件当作排错手段；复用既有请求关联，先查再重试，不通过“再开一家商户”或“关闭后重建”绕过故障。关闭控台商户不等于清除测试记录。 - **存量恢复已作废**：原“仅恢复 6666000241335656”的要求随 02 关闭而取消，该商户只保留为通道能力的验证来源（见文首修订说明）。不批量修复或重新打开其他小微商户这条约束继续有效。 - **两票并行、互不阻塞**：新企业商户的分阶段流程（03）与微信实名能力（04）同时推进，不存在先后门，也不再设阶段切换条件。开工门槛是“通道能力已被真实证明”，该条件已满足并归档。 - **真实测试数据约束**：普通自动化测试全部模拟汇付，不创建真实商户。真实联调也不能把反复真实新进件当作排错手段；复用既有请求关联，先查再重试，不通过“再开一家商户”或“关闭后重建”绕过故障。关闭控台商户不等于清除测试记录。 - **共享文件**：只在授权业务区域做必要增量改动，不顺手重构共享服务、路由或公共配置。 ## Testing Decisions @@ -119,7 +119,7 @@ - 对外部请求可验证关键合同字段、请求关联和必要调用次数，因为它们决定是否重复办理；不锁死内部方法顺序、私有字段或实现分支。 - 使用按商户 ID/申请号隔离的数据，不依赖共享测试库全表数量或其他测试的执行顺序。 - 常规自动化测试模拟汇付，不对真实商户提交开通、授权或支付请求。指定存量商户的真实结果作为另外记录的验收证据。 - 真实联调严格分阶段：先验收 6666000241335656，再开展新商户完整流程；阶段一禁止真实新进件。阶段二先完成模拟测试，再以实际需要的企业进件作验收，不反复创建测试商户试错。 - 真实联调先完成模拟测试，再以实际需要的企业进件作验收，不反复创建测试商户试错；不调用真实新商户进件接口做排错。 ### 测试模块与先例 @@ -147,8 +147,8 @@ | 通道已经开启全部必要能力 | 两端显示一致的已完成结果与同步时间 | | 资料或行业不匹配 | 给出具体补充/纠正项，不照搬平台服务类目 | | 存量指定商户恢复 | 原汇付商户号、已成功步骤和银行卡保持关联 | | 指定存量商户未取得真实开通成功证据 | 不进入新商户完整流程实施与真实新进件联调；明确记录仍待完成的条件 | | 指定存量商户满足阶段切换条件 | 留存汇付结果及核验时间，随后进入新商户完整流程 | | 通道能力尚未被真实证明 | 不开展真实新商户进件联调；明确记录仍待完成的条件 | | 通道能力已由真实接口证明 | 留存汇付结果及核验时间（见 [核验证据](evidence-2026-09-15.md)），可开展新商户流程实施 | | 自动化测试或联调失败 | 自动化测试不调用真实新进件；联调先查原申请，不能反复创建新商户绕过失败 | | 其他已关闭小微商户 | 不被本次恢复扫描、补开或更改状态 | | 商户尝试访问其他商户申请 | 请求被权限边界拒绝，不能泄露或推进他人资料 | @@ -197,8 +197,8 @@ ### 交付完成条件 商户端与后台可完成受权限约束的刷新及局部重试；无回调场景能按人工操作推进到真实已完成或明确待办理状态；指定存量商户复用原身份恢复缺项，新企业商户可走同一闭环；必要能力以通道证据确认，测试与无法验证的外部条件均有记录。 商户端与后台可完成受权限约束的刷新及局部重试；无回调场景能按人工操作推进到真实已完成或明确待办理状态；新企业商户按进件 → 微信业务开通 → 微信实名分阶段推进，未完成实名与授权不解锁收款；必要能力以通道证据确认，测试与无法验证的外部条件均有记录。 交付证据必须体现先后顺序：先记录指定存量商户满足阶段切换条件的通道证据，再记录新商户流程实施与验收结果。指定商户尚未开通成功时，阶段一尚未完成，不能用“新商户能进件”替代其验收。 交付证据必须区分“通道能力已验证”与“新商户流程已验收”：前者由存量商户上的真实接口结果证明并已归档，后者需要新商户上的真实进件与开通结果，不能用“新商户能进件”替代收款能力与实名的证据。 Status 表示规格已按技能发布并可由代理执行技术核查与实现，不表示功能已经实现或真实商户已经恢复。 .scratch/merchant-wechat-onboarding/ticket-plan.md
@@ -1,31 +1,37 @@ # 企业商户进件与微信开通：已确认任务拆分 状态：用户已确认。2026-09-16 因需求变更（不做一键进件、实名走法人、未完成实名不允许收款）调整为三张执行工单。 日期：2026-09-15 首次发布，2026-09-16 修订。 状态：用户已确认。2026-09-16 因需求变更（不做一键进件、实名走法人、未完成实名不允许收款）调整为三张工单，同日因用户不再需要测试商户 6666000241335656 关闭其中 02，现为两张并行工单。 日期：2026-09-15 首次发布；2026-09-16 修订两次。 依据：[完整规格](spec.md) 与 [ADR 0001](../../docs/adr/0001-merchant-onboarding-and-wechat-provisioning.md) 的 2026-09-16 修订。三张执行工单均直接引用规格。 依据：[完整规格](spec.md) 与 [ADR 0001](../../docs/adr/0001-merchant-onboarding-and-wechat-provisioning.md) 的 2026-09-16 修订。 ## 工单 | 编号 | 任务 | Blocked by | Status | | --- | --- | --- | --- | | 02 | [完成指定存量商户微信与资金能力开通](issues/02-existing-merchant-wechat-activation.md) | 无，可先开始 | ready-for-agent | | 03 | [新企业商户进件与分阶段开通微信收款能力](issues/03-new-enterprise-onboarding.md) | 02 真实验收成功 | ready-for-agent | | 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 | ## 执行规则 **阶段一（02）**复用 6666000241335656 的已有商户号，把微信业务三场景、人才端 AppID、延迟入账和 D1 自动结算办妥并取得汇付侧真实证据。该商户的实名与授权已移交 04，不在 02 的验收范围内。 两张工单**并行推进、互不阻塞**，不设先后门。开工门槛是“通道能力已被真实接口证明”：微信业务三场景即时入驻成功、延迟入账生效、人才端 AppID 绑定成功都已经在存量商户上验证并归档在 [核验证据](evidence-2026-09-15.md)。 **阶段二（03）**接入新增企业商户的分阶段流程：一次收齐资料，之后按阶段手动推进基本进件 → 微信业务开通 → 微信实名认证，两端刷新查看。不做“一次进件即完成收款能力”。 **03** 接入新增企业商户的分阶段流程：一次收齐资料，之后按阶段手动推进基本进件 → 微信业务开通 → 微信实名认证，两端刷新查看。不做“一次进件即完成收款能力”。 **04 与 03 并行**，不受任何票阻塞。它之所以独立成票，是为了解开 02 ⇄ 03 的死锁：02 的阶段切换条件原本要求指定商户实名/授权已确认成功，而实名发起能力当前为零；把它留在 02 里，就会出现“阶段二要等阶段一、阶段一又要等阶段二才建的能力”。 **04** 交付微信实名认证的发起能力与授权状态闭环，并把它纳入收款就绪判定。按用户决策：**实名走法人**（进件只新增法人手机号一项），**未完成实名与授权前不允许商户收款**。 02 仍在审核、请求未知或缺少生效证据时，03 不能开始。**“待实名”不再是阻塞项**：它是收款能力的真实缺项，按规格「收款就绪的前提」在实名完成前不能收款，但不妨碍阶段二开工。 02 已关闭，不再执行其剩余验收。它的产出不因此作废：三个真实缺陷修复已合入，通道能力已证明，证据已归档。指定存量商户保持“待实名”，不再是任何一票的验收条件或阻塞项。 模拟测试通过、接口受理成功或本地标记成功均不解除阻塞。ready-for-agent 表示工单可由代理承接，不代表没有依赖或已经完成。 模拟测试通过、接口受理成功或本地标记成功均不等同于真实验收。ready-for-agent 表示工单可由代理承接，不代表已完成。 每个独立 Issue 包含自身验收条件及共同约束。自动化使用模拟汇付响应，不创建真实商户；真实联调失败先核对原申请，不反复新进件制造控台记录。 ### 两张票的冲突面 - **进度服务**：03 要按申请单通用地重做分阶段进度并去掉只服务一张商户的恢复路径，04 要往里加实名阶段。04 先做时不要为实名加深对现有硬编码的依赖，否则 03 要返工。 - **商户端进件表单**：04 加法人手机号，03 加行业与材料校验。谁先落地谁先改，另一张做增量。 - **共享文件**：`application.yml`、`AdminBusinessService.java`、`CONTEXT.md` 等只做自己范围内的增量小改，不顺手整理。 ## 确认记录 @@ -34,3 +40,4 @@ - 2026-09-15：用户同意删除冗余的 01 总任务，两张工单直接引用规格；保留原编号及 02 → 03 的依赖。 - 2026-09-16：用户确认需求变更——不做一键进件同时完成收款能力，改为一次性收录资料加分阶段手动推进；扫码授权由本人完成，平台不追求全自动。据此修订 03 口径。 - 2026-09-16：用户确认“实名走法人”（只新增法人手机号字段，不选需要盖章授权函的经办人）与“未完成实名/授权前不允许商户收款”。据此新增 04，并从 02 的阶段切换条件中移除实名，解开死锁。 - 2026-09-16：用户确认不再需要 6666000241335656 做测试。02 关闭（wontfix），03 解除阻塞改为可立即开始，04 的成立理由回到“任何商户要能收款都需要实名”。规格中“先存量、后新商户”的两阶段框架与阶段切换条件整体作废，02 只保留为通道能力的验证来源。
