| .scratch/merchant-wechat-onboarding/issues/02-existing-merchant-wechat-activation.md | ●●●●● 补丁 | 查看 | 原始文档 | blame | 历史 | |
| .scratch/merchant-wechat-onboarding/issues/03-new-enterprise-onboarding.md | ●●●●● 补丁 | 查看 | 原始文档 | blame | 历史 | |
| .scratch/merchant-wechat-onboarding/issues/04-wechat-realname-application.md | ●●●●● 补丁 | 查看 | 原始文档 | blame | 历史 | |
| .scratch/merchant-wechat-onboarding/spec.md | ●●●●● 补丁 | 查看 | 原始文档 | blame | 历史 | |
| .scratch/merchant-wechat-onboarding/ticket-plan.md | ●●●●● 补丁 | 查看 | 原始文档 | blame | 历史 | |
| CONTEXT.md | ●●●●● 补丁 | 查看 | 原始文档 | blame | 历史 | |
| docs/adr/0001-merchant-onboarding-and-wechat-provisioning.md | ●●●●● 补丁 | 查看 | 原始文档 | blame | 历史 |
.scratch/merchant-wechat-onboarding/issues/02-existing-merchant-wechat-activation.md
@@ -1,25 +1,25 @@ # 02 — 完成指定存量商户微信与资金能力开通 **What to build:** 复用 6666000241335656 已有商户号，通过商户端和后台刷新、补开与局部重试，完成微信支付、人才端 AppID、适用实名/授权、延迟入账及 D1 自动结算核验，取得汇付侧真实成功证据。 **What to build:** 复用 6666000241335656 已有商户号，通过商户端和后台刷新、补开与局部重试，完成微信支付、人才端 AppID、延迟入账及 D1 自动结算核验，取得汇付侧真实成功证据。该商户的实名与授权已移交 [04](04-wechat-realname-application.md)，不在本票范围内。 Blocked by: None — can start immediately Status: ready-for-agent - [ ] 先核实官方查询、补开、配置及实名接口和状态语义，只读核对目标商户原申请与实际配置，明确缺项；不能预设卡住原因。 - [x] 先核实官方查询、补开、配置及实名接口和状态语义，只读核对目标商户原申请与实际配置，明确缺项；不能预设卡住原因。 - [ ] 商户端和后台均能刷新尚未整体通过的申请，展示一致的分阶段进度、最后同步时间、具体原因与下一步；权限与敏感信息展示符合规格。 - [ ] 基础审核通过后按通道前置要求补齐微信能力，公共配置参考 6666000226048687 的三个场景、0.70% 费率、最低收费 0 元、内扣实收和渠道规则；商户行业与资质按实际情况使用。 - [x] 基础审核通过后按通道前置要求补齐微信能力，公共配置参考 6666000226048687 的三个场景、0.70% 费率、最低收费 0 元、内扣实收和渠道规则；商户行业与资质按实际情况使用。 - [ ] 衔接人才端 AppID 配置和实名/授权，必要材料可补充，需要商户本人办理的步骤提供有效指引；办理后通过手动刷新同步结果。 - [ ] 补齐并核实延迟入账开启、强制延迟关闭、D1 自动批次结算、起结与留存均为 0。已配置正确的能力保持，不能仅凭请求中带参数判定生效。 - [x] 补齐并核实延迟入账开启、强制延迟关闭、D1 自动批次结算、起结与留存均为 0。已配置正确的能力保持，不能仅凭请求中带参数判定生效。 - [ ] 基本进件成功后不重建商户或银行卡；失败只重试失败步骤，未知结果先查询，未决申请不重复提交。 - [ ] 手动刷新与有效回调按一致规则推进；重复点击、并发入口、重复或乱序通知不会重复补开或破坏同次尝试的成功结果。 - [ ] 缺少必要能力证据时不能显示全部完成；超时保留最后有效状态，查询错误与审核拒绝区分。 - [ ] 完成模拟集成测试、权限与页面验收，覆盖无回调推进、局部重试、未知结果、幂等、待实名及能力缺失；完成相关资金语义回归。 - [ ] 使用已交付的操作入口恢复指定商户，记录真实微信能力、人才端绑定、适用实名/授权、延迟和结算结果及核验时间；两端显示与通道一致。 - [ ] 使用已交付的操作入口恢复指定商户，记录真实微信能力、人才端绑定、延迟和结算结果及核验时间；两端显示与通道一致。**实名与授权不在本票验收范围内**，已移交 [04](04-wechat-realname-application.md)：平台此前没有任何实名发起能力，指定商户的实名在该能力建成后办理。 - [ ] 整个阶段没有真实新商户进件，不操作其他已关闭小微商户，不修改参考商户。 - [ ] 真实商户仍在审核、待实名、请求未知或缺少生效证据时，保留具体待办，本票不得标完成，03 继续阻塞。 - [ ] 真实商户仍在审核、请求未知或缺少生效证据时，保留具体待办，本票不得标完成。**“待实名”不再阻塞本票完成，也不再阻塞 03**：它是收款能力的真实缺项（见规格「收款就绪的前提」），由 04 办理；把它留在阻塞条件里会造成 02 ⇄ 03 死锁。 **完成演示：** 在商户端或后台手动刷新指定商户，全部必要能力显示已确认，且有可核对的汇付侧证据；商户号与银行卡保持原关联。 **完成演示：** 在商户端或后台手动刷新指定商户，微信支付三场景、人才端 AppID、延迟入账与 D1 自动结算显示已确认，且有可核对的汇付侧证据；商户号与银行卡保持原关联。实名与授权按规格「收款就绪的前提」显示为待办理，且在该能力建成前不影响本票完成。 ## 规格与共同约束 @@ -35,6 +35,12 @@ ## Comments - 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 继续阻塞。 - 2026-09-15 第二轮真实接口核验：凭据轮换（`sys_id` 改为目标商户直属上级 `6666000220591054`）后 20002 阻塞解除，已用六个只读端点取到目标商户与参考商户的真实状态，第一条「核实接口与状态语义、明确缺项」已满足。目标商户真实状态：基础进件**已通过**（`apply_status=Y`、`reg_status=S`、`bind_card_status=S`、`settle_status=S`，原申请未带微信业务），`mer_stat=NORMAL`，直属 `6666000220591054`，结算卡仍是原卡（尾号 7957）；**微信能力完全未开**（微信配置列表缺省、费率「未查到商户费率配置信息」、实名「AT入驻信息池信息不存在」、详情无 `qry_wx_conf_list`）；**延迟入账未开**（`delay_flag=N`，`forced_delay_flag=N` 已符合）；**D1 自动批次结算与起结／留存已符合**（`settle_status=1`、`settle_cycle=D1`、`settle_pattern=P0`、`min_amt=0.00`、`remained_amt=0.00`）。阶段二四项合同未知项已逐项裁定：最低收费省略入参、以读回 `0.00` 为验收；`fee_charge_type` 不是微信写入字段，内扣写入路径是公共参数 `out_fee_flag=2`，验收读回 `fee_charge_type=1`；渠道 `00016904` 为真实生效渠道，可不送 `pay_channel_id` 用渠道默认；线上 CID 依官方费率规则表企业线上唯一一条 `fee_rule_id=756`（细分含「就业信息平台／其他信息服务平台」），场景 12 全表无独立行、随 4/5 共用线上规则（参考商户 4/5/12 真实同为 0.70%）。参考商户实测人才端 AppID `wxcfee477acb54d179` 已以 `config_type=1` 绑定在 `fee_type=01`／`bank_channel_no=00016904` 下且无管控，并留下 `APPLYMENT_STATE_FREEZED` ＋ `authorize_stat=1` 的真实样本。详细记录见 [核验证据](../evidence-2026-09-15.md)。仍缺：真实补开与人才端绑定、延迟入账开启、实名／授权、两端页面真实验收、回调与幂等验收；另本地申请 449 仍停在 `pending`，与通道 `apply_status=Y` 不一致，刷新须能推进基础阶段。本票未完成，03 继续阻塞。 - 2026-09-15 实施检查点：已完成指定商户原申请只读核对和基础进度保护，五个模拟集成场景通过。当前身份查询自身成功、查询指定商户及用户另行授权的下级对照商户均为 20002；以目标商户作为 sys_id 沿用当前凭据查询自身返回 HTTP 922 空响应，尚未确认可用权限。详细记录见 [核验证据](../evidence-2026-09-15.md)。补开、两端页面、实名/AppID、回调和完整验收尚未交付，本票未完成，03 继续阻塞。 - 2026-09-15：用户已确认两票拆分与 02 → 03 依赖，按 to-tickets 技能发布，标记 ready-for-agent。发布工单不表示已实施或验收通过。 .scratch/merchant-wechat-onboarding/issues/03-new-enterprise-onboarding.md
@@ -1,29 +1,35 @@ # 03 — 完成新企业商户一次进件与微信开通流程 # 03 — 新企业商户进件与分阶段开通微信收款能力 **What to build:** 02 真实验收通过后，新企业商户在商户端一次提交主体、实际行业材料和银行卡，即可沿已经验证的公共能力完成基本进件及微信开通；无回调时由两端手动刷新继续办理，失败可局部重试。 **What to build:** 02 真实验收通过后，新企业商户在商户端一次提交收齐主体、经营与结算资料，之后**按阶段手动推进**：基本进件 → 微信支付业务开通 → 微信实名认证，两端刷新查看通道结果。**不做“一次进件即完成收款能力”**——微信侧的审核与授权是多段异步外部流程，其中授权必须由本人扫码，平台无法在提交那一刻走完。 Blocked by: 02 — 完成指定存量商户微信与资金能力开通。 Blocked by: 02 — 完成指定存量商户微信与资金能力开通。**02 的“待实名”不阻塞本票**（原阶段切换条件已修订，见规格与 ADR 0001 的 2026-09-16 修订）。 Status: ready-for-agent - [ ] 开始本票实现及真实新进件联调之前，核对 02 的真实成功证据；等待实名、接口受理或仅模拟通过不能解除阻塞。 - [ ] 复用现有企业进件表单和 02 已验证的公共能力，完成实际行业与所需材料校验、开通意图保存及企业基本进件衔接。 - [ ] 开始本票实现及真实新进件联调之前，核对 02 的真实成功证据；接口受理或仅模拟通过不能解除阻塞。等待实名不再作为解除条件。 - [ ] 复用现有企业进件表单和 02 已验证的公共能力，完成实际行业与所需材料校验、开通意图保存及企业基本进件衔接；进件一次收齐后续各阶段所需资料。 - [ ] 进件表单的资料收录以 [04](04-wechat-realname-application.md) 新增的**法人手机号**为准（该字段属于实名的前置，04 不被阻塞可先落地）；04 先落地则直接复用，不重复加字段。 - [ ] 商户可理解适用费率与待补材料，渠道技术参数由平台维护；不复制参考商户独有身份与资质。 - [ ] **分阶段手动推进**：进件完成后向商户提供可执行的“下一步”，商户推进微信支付业务开通；开通完成后推进微信实名认证；每阶段之后刷新查看通道结果。尚未完成的阶段不得显示为完成，缺证据时给出具体缺项。 - [ ] **进度与刷新去硬编码**：现有分阶段进度与刷新只对常量 `RECOVERY_HUIFU_ID = "6666000241335656"` 生效（`MerchantOnboardingProgressService.supports()`）。必须改成按申请单通用，让新商户走进同一套分阶段视图；`merchant_onboarding_progress` 已按 `application_id` 建表，结构上支持。 - [ ] **微信业务开通的商户手动入口**：当前业务开通是进件后由回调或刷新在服务端静默执行的，存量补开入口 `HuifuOnboardingProgressGateway.openWechat` 仍是抛异常的占位（`"Wechat business profile is not confirmed"`）。需要给商户端与后台提供可推进的入口，同时保留服务端自动路径。 - [ ] 一次提交保存唯一申请关联；基础审核未确认成功前不越过前置条件，确认后继续微信与资金能力办理。 - [ ] 商户端与后台显示一致的基本审核及后续配置状态，提供刷新、具体失败提示和可执行下一步；普通状态读取保持只读。 - [ ] 基础审核拒绝与后续开通失败区分处理；基本进件成功后的局部失败保留原商户号和银行卡，未知结果先查，重复提交不产生重复商户。 - [ ] 新商户同样满足三个微信场景、人才端 AppID、适用实名/授权、延迟非强制及 D1 自动结算等完整开通条件。 - [ ] 模拟测试覆盖一次提交到全部完成、基础审核拒绝、材料缺失、待实名、步骤失败、超时、并发、权限及能力不全，并完成两端页面验收。 - [ ] 新商户同样满足三个微信场景、人才端 AppID、适用实名/授权、延迟非强制及 D1 自动结算等完整开通条件；未完成微信实名认证与授权前不解锁收款（见规格「收款就绪的前提」）。 - [ ] 模拟测试覆盖一次提交后**各阶段依次推进**、基础审核拒绝、材料缺失、待实名、步骤失败、超时、并发、权限及能力不全，并完成两端页面验收。 - [ ] 先完成模拟验证，再对实际需要的新企业进件做真实验收，保留原请求与通道证据；禁止反复创建测试商户排错。 - [ ] 若没有适合的真实新商户或仍有外部待办，如实记录真实验收未完成，不伪造通过。 - [ ] 相关回归满足到店消费支付即核销且不延迟、预购核销并完成交易确认后才可结算；不扩大既定业务范围。 **完成演示：** 新企业从一次提交到基本审核、微信与资金能力开通形成闭环；无回调时手动刷新也可推进，真实验收发生在 02 成功之后。 **完成演示：** 新企业一次提交收齐资料后，两端能看到分阶段进度，并可依次推进基本审核、微信支付业务开通与微信实名认证；每阶段以通道证据判定完成，刷新可继续推进。未完成微信实名认证与授权前，收款判定为不就绪。 ## 规格与共同约束 [完整规格](../spec.md) - 决策依据见 [ADR 0001](../../../docs/adr/0001-merchant-onboarding-and-wechat-provisioning.md) 的 2026-09-16 修订：不做“一次进件即完成”、实名走法人、未完成实名不允许收款。 - 实名发起能力由 [04](04-wechat-realname-application.md) 单独交付，与本票并行；本票只负责在阶段进度里衔接它，不重复实现。 - 查询、补开、实名、资金配置、两端页面及测试都归入对应业务阶段，不再单独拆票。 - 复用已有进件服务、通道适配与页面，只做完成当前阶段所需的最小整理，不单列预重构。 - 使用已确认测试边界：进件服务公开操作为主入口，真实测试库、模拟汇付响应，补充接口权限、通道合同与页面验收。 @@ -34,4 +40,6 @@ ## Comments - 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
New file @@ -0,0 +1,37 @@ # 04 — 微信实名认证发起与授权闭环 **What to build:** 让平台能发起微信实名认证申请并闭环授权状态：进件时一次收齐法人手机号，基础进件与微信业务开通到位后由两端入口发起实名，展示授权二维码供本人扫描，并把实名与授权纳入收款就绪判定。本票不依赖 02 的真实证据，与 03 并行推进。 Blocked by: None — 可立即开始（它正是解开 02 ⇄ 03 死锁的那一票）。 Status: ready-for-agent - [ ] 新建实名申请通道适配：调用 `v2.merchant.busi.realname` 发起申请，走法人（`contact_type=LEGAL`），必填法人姓名、法人手机号、法人身份证号；企业另填 `owner` 与 `identification_address`。现有仓库只有 `v2.merchant.busi.realname.query` 查询，提交接口需要新建。 - [ ] 进件表单新增法人手机号并在申请记录持久化。这是走法人路线的唯一新增字段（法人姓名、证件号、证件有效期、证件居住地址已由现有进件采集）。不得复用联系人手机号冒充法人手机号。 - [ ] 发起前校验前置条件：商户必须已成功入驻微信、且所需能力已开通；材料不齐时给出具体缺项而不是提交后被驳回。材料上传复用现有图片上传通道，文件类型按官方要求。 - [ ] 商户端与后台都能发起实名并展示状态；需要本人办理时展示通道回传的授权二维码。二维码渲染两端已实现（商户端与后台详情页均渲染 `qrcode_data`），本票只负责把它接上，不重复实现。 - [ ] 授权完成判定必须是申请单审核通过**且**授权成功：`APPLYMENT_STATE_PASSED` 单独不成立，`authorize_stat` 必须为 `1`。 - [ ] 修正 `FREEZED` 的判定：`APPLYMENT_STATE_FREEZED` 同时返回 `authorize_stat=1` 时，授权其实已经成功，不能显示成“待办理”；要展示官方 `reject_reason` 与指引。 - [ ] 业务开通异步通知补读 `real_name_applyment_stat` 与 `qrcode_data`：通道会把实名状态与授权二维码推到现有 `merchant-business-open-notify` 回调，当前处理器一个字段都没读。 - [ ] 未决申请不重复提交：以 `applyment_stat` 状态机判断，`EDITTING`／`WAITTING_*` 保持原申请；`REJECTED` 时按官方要求更换业务申请编号重来，未知结果先查询。重复点击、并发入口、重复或乱序通知不产生多份实名申请。 - [ ] 收款就绪纳入实名：未完成微信实名认证与授权前不允许收款。`MerchantPaymentReadinessService` 当前只看进件审核通过、结算卡 token、通道账户状态、自动结算与取现能力，必须补上微信业务开通与实名/授权。 - [ ] 模拟集成测试覆盖：材料不齐拒绝、发起受理、审核中、审核通过但未授权、授权成功、`FREEZED` 且已授权、驳回后换号重提、查询错误保留最后有效状态、并发与重复通知幂等；完成两端页面与权限验收。 - [ ] 实名属于需要本人办理的步骤，提供可执行指引；不得把本地状态改写成通道已授权，也不得在缺少通道证据时显示完成。 - [ ] 范围外（交易、退款、核销、登录）只读记录并交接；不修改参考商户，不创建真实测试商户。 **完成演示：** 在商户端或后台对指定存量商户发起微信实名认证，状态随通道推进（审核中／待本人办理／已授权），本人扫码后刷新显示授权成功；未完成实名时收款判定为不就绪并给出缺项。 ## 规格与共同约束 [完整规格](../spec.md) - 决策依据见 [ADR 0001](../../../docs/adr/0001-merchant-onboarding-and-wechat-provisioning.md) 的 2026-09-16 修订：实名走法人、未完成实名不允许收款、不做“一次进件即完成”。 - 复用已有进件服务、通道适配与页面，只做完成本阶段所需的最小整理，不单列预重构。 - 普通自动化测试不得创建真实汇付商户。真实联调先查询原申请再处理失败，不能通过反复进件或关闭重建制造商户记录。 - 只追加必要迁移，共享文件最小增量；同一 checkout 只运行一个 Maven 构建。 - 二维码展示已由 02 的两端页面实现并已验证渲染，本票不重做。 - 每票验收依据完整规格；下列条件突出该阶段的交付，不删减规格中的其他约束。 ## Comments - 2026-09-16：用户确认“实名走法人”“未完成实名前不允许商户收款”两项决策后发布。本票从 03 的实名条款拆出**并解除其与 02 的依赖**：02 的阶段切换条件原本要求指定商户实名/授权已确认成功，而实名发起能力当前为零，形成“阶段二要等阶段一、阶段一又要等阶段二才建的能力”的死锁。规格中的阶段切换条件已同步修订，“等待实名”不再阻塞阶段切换。发布工单不表示已实施或验收通过。 .scratch/merchant-wechat-onboarding/spec.md
@@ -19,6 +19,8 @@ 商户在商户端一次提交企业主体、经营和结算资料，平台同时保存微信业务开通意图。基本进件审核通过后，平台按汇付要求完成微信业务、人才端 AppID 配置、必要的实名/授权以及延迟入账和自动结算核验。商户端和后台显示各阶段的真实进度、失败原因与可执行的下一步。 微信实名认证走法人（`contact_type=LEGAL`）：实名申请使用法人信息发起，进件表单一次收齐所需材料，为此新增法人手机号一项。微信侧的审核、账户验证、签约与授权是多段异步外部流程，其中授权必须由本人扫描通道回传的小程序码，因此按阶段推进、由两端刷新查看，不追求“一次进件即完成收款能力”。**未完成微信实名认证与授权前，商户不能收款。** 微信业务公共配置参考商户 6666000226048687：保留线上公众号、小程序、反扫三个场景，费率 0.70%，最低收费 0 元，内扣、实收；行业、主体、证照、银行卡及实名信息按实际商户办理。实际支付 AppID 使用人才端配置。 本地收不到回调时，商户或运营点击“刷新进度”，由平台主动查询汇付，并继续已经满足前置条件的开通步骤。保留回调，不增加进件定时查询或页面自动轮询。配置失败仅重试失败步骤，不重建已通过的进件和银行卡关系。 @@ -82,6 +84,7 @@ - **一次提交、分阶段办理**：保存一次进件意图及资料，按通道真实前置条件执行基本审核、业务开通、微信配置、实名/授权和能力核验。具体业务开通与 AppID 配置的调用先后以官方要求为准，不能凭现有调用顺序认定正确。 - **状态分离**：至少区分基础审核、微信业务、人才端 AppID 配置、实名/授权、延迟入账、自动结算。商户端使用可理解的阶段摘要，后台同时显示必要通道诊断信息。未知、等待、失败和已生效不得合并成同一种状态。 - **完成判定**：获得汇付商户号或提交受理成功不足以判定开通完成。必须有通道有效证据证明商户基础状态、所需微信能力、人才端绑定、适用实名/授权要求、延迟入账及自动结算满足条件。缺少证据时显示未确认并给出原因。 - **收款就绪的前提**：**未完成微信实名认证与授权前，商户不能收款。** 收款就绪判定必须包含微信支付业务开通与实名/授权，不能只凭进件审核通过、结算银行卡与取现能力得出。实名未完成是收款能力的真实缺项，不作为可忽略的合规补课。 - **查询入口**：普通状态读取保持只读，新增或扩展显式“刷新进度”写操作，商户端与管理后台调用同一进度同步逻辑。刷新可能继续办理后续开通，界面提示这个效果。后台入口不再要求申请已经整体通过。 - **刷新语义**：先查询当前未决步骤及必要能力，更新已知结果，再在前置成功且不存在未决重复申请时继续开通。单次刷新有界返回，不循环等待人工审核完成；必要时提示稍后再次刷新。 - **同步时机**：仅通过手动刷新和已有回调推进本次进件；不新增进件定时查询、页面自动轮询，也不把推进逻辑接入已有能力定时刷新。其他既有交易补偿任务属于范围外。 @@ -91,10 +94,11 @@ - **持久化**：优先扩展已有申请和步骤字段，保存必要状态、原请求日期和流水号、通道申请单号、尝试关联、结果码、最后同步时间及脱敏证据。具体新增列在实现前检查现有结构后决定；如需迁移，使用最新共享版本号追加，禁止修改已执行迁移。 - **返回契约**：两端返回一致的分阶段进度、最后成功同步时间、当前同步错误、可执行操作与失败原因；保留已有消费者所需的兼容信息。最终端点名与字段命名由实现时沿用仓库风格确定。 - **权限与信息展示**：商户入口按登录商户和门店权限定位申请，不信任前端传入的任意汇付商户号；后台沿用既有运营权限。对商户展示可处理的业务提示，对运营提供必要的脱敏诊断信息。 - **实名/签约**：需要商户本人完成的实名、授权或签署通过通道提供的指引办理，不能将本地状态改写为通道已授权。接口能否发起实名及所需材料属于实施前核查事项。 - **实名/签约**：需要商户本人完成的实名、授权或签署通过通道提供的指引办理，不能将本地状态改写为通道已授权。**“接口能否发起实名及所需材料”的核查已完成（2026-09-15）**：平台当前没有任何实名发起能力，全仓只有 `v2.merchant.busi.realname.query` 查询，实名申请接口 `v2.merchant.busi.realname` 必须新建；走法人只需法人姓名、证件号、证件有效期与证件居住地址（进件已有）加**法人手机号**（进件新增）；实名分两个阶段，`APPLYMENT_STATE_PASSED` 只表示申请单审核通过，还要 `authorize_stat=1` 才算授权完成，而授权由本人扫描通道回传的小程序码完成，平台只能展示该二维码并查询状态。 - **存量恢复**：仅恢复 6666000241335656。先只读核对本地关联、汇付审核和实际配置，再复用原商户号补齐缺失能力。保留已成功步骤与银行卡，不批量修复或重新打开其他小微商户。 - **阶段一优先且阻塞阶段二**：先完成指定存量商户微信开通所需的查询、补开、实名/授权衔接及必要能力核验，并取得汇付侧成功证据；阶段一只实现和验证这些工作所需的公共能力，不先扩展新商户完整进件流程，不调用真实新商户进件接口。 - **阶段切换条件**：指定商户的微信业务、人才端 AppID 和适用实名/授权已确认成功，并核实延迟入账及自动结算满足本规格。受理成功、处理中、等待实名、超时或仅本地成功都不能通过该条件。记录真实结果和时间后，再进入新增企业商户“进件 + 微信业务开通”流程的实现与联调。 - **阶段切换条件**：指定商户的微信业务与人才端 AppID 已确认成功，并核实延迟入账及自动结算满足本规格。受理成功、处理中、超时或仅本地成功都不能通过该条件。记录真实结果和时间后，再进入新增企业商户“进件 + 微信业务开通”流程的实现与联调。 - **“等待实名”不是阶段切换的阻塞项**：实名需要平台先具备发起能力，而该能力当前为零。把它列为阶段切换条件会造成死锁——阶段二要等阶段一完成，阶段一又要在阶段二里才建起来。**实名发起能力单独立票、与阶段二并行推进**，指定商户的实名在其建成后办理；在此之前指定商户保留“待实名”待办，不影响阶段二开工。 - **真实测试数据约束**：普通自动化测试全部模拟汇付，不创建真实商户。阶段二也不能把反复真实新进件当作排错手段；复用既有请求关联，先查再重试，不通过“再开一家商户”或“关闭后重建”绕过故障。关闭控台商户不等于清除测试记录。 - **共享文件**：只在授权业务区域做必要增量改动，不顺手重构共享服务、路由或公共配置。
@@ -1,22 +1,29 @@ # 企业商户进件与微信开通：已确认任务拆分 状态：用户已确认，两个独立 Issue 已发布。 日期：2026-09-15。 状态：用户已确认。2026-09-16 因需求变更（不做一键进件、实名走法人、未完成实名不允许收款）调整为三张执行工单。 日期：2026-09-15 首次发布，2026-09-16 修订。 依据：[完整规格](spec.md)。仅保留 02、03 两张执行工单，均直接引用规格。 依据：[完整规格](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 | | 03 | [新企业商户进件与分阶段开通微信收款能力](issues/03-new-enterprise-onboarding.md) | 02 真实验收成功 | ready-for-agent | | 04 | [微信实名认证发起与授权闭环](issues/04-wechat-realname-application.md) | 无，与 03 并行 | ready-for-agent | ## 执行规则 先执行 02，复用 6666000241335656 的已有商户号，把微信、人才端 AppID、适用实名/授权、延迟入账和 D1 自动结算办妥并取得汇付侧真实证据；再执行 03，接入新增企业商户完整流程。 **阶段一（02）**复用 6666000241335656 的已有商户号，把微信业务三场景、人才端 AppID、延迟入账和 D1 自动结算办妥并取得汇付侧真实证据。该商户的实名与授权已移交 04，不在 02 的验收范围内。 02 仍在审核、待实名、未知或缺证据时，03 不能开始。模拟测试通过、接口受理成功或本地标记成功均不解除阻塞。ready-for-agent 表示工单可由代理承接，不代表没有依赖或已经完成。 **阶段二（03）**接入新增企业商户的分阶段流程：一次收齐资料，之后按阶段手动推进基本进件 → 微信业务开通 → 微信实名认证，两端刷新查看。不做“一次进件即完成收款能力”。 **04 与 03 并行**，不受任何票阻塞。它之所以独立成票，是为了解开 02 ⇄ 03 的死锁：02 的阶段切换条件原本要求指定商户实名/授权已确认成功，而实名发起能力当前为零；把它留在 02 里，就会出现“阶段二要等阶段一、阶段一又要等阶段二才建的能力”。 02 仍在审核、请求未知或缺少生效证据时，03 不能开始。**“待实名”不再是阻塞项**：它是收款能力的真实缺项，按规格「收款就绪的前提」在实名完成前不能收款，但不妨碍阶段二开工。 模拟测试通过、接口受理成功或本地标记成功均不解除阻塞。ready-for-agent 表示工单可由代理承接，不代表没有依赖或已经完成。 每个独立 Issue 包含自身验收条件及共同约束。自动化使用模拟汇付响应，不创建真实商户；真实联调失败先核对原申请，不反复新进件制造控台记录。 @@ -25,3 +32,5 @@ - 2026-09-15：用户要求降低任务粒度，由六票收敛为两个业务阶段。 - 2026-09-15：用户回复“确认”，批准按两票发布。 - 2026-09-15：用户同意删除冗余的 01 总任务，两张工单直接引用规格；保留原编号及 02 → 03 的依赖。 - 2026-09-16：用户确认需求变更——不做一键进件同时完成收款能力，改为一次性收录资料加分阶段手动推进；扫码授权由本人完成，平台不追求全自动。据此修订 03 口径。 - 2026-09-16：用户确认“实名走法人”（只新增法人手机号字段，不选需要盖章授权函的经办人）与“未完成实名/授权前不允许商户收款”。据此新增 04，并从 02 的阶段切换条件中移除实名，解开死锁。 CONTEXT.md
@@ -38,4 +38,6 @@ **微信支付开通**：商户取得在平台小程序内接受微信付款所需业务能力的过程。开通失败可以单独重试，不否定已经通过的基本资料审核。 **微信待实名**：微信支付开通过程中，仍需商户完成实名或授权的阶段，不属于开通失败。 **微信待实名**：微信支付开通过程中，仍需完成微信实名认证与授权的阶段，不属于开通失败。实名认证走法人（`contact_type=LEGAL`），申请以法人信息发起；申请单审核通过（`APPLYMENT_STATE_PASSED`）不等于授权完成，还要由本人扫描通道回传的小程序码、并满足 `authorize_stat=1`。这是收款能力的真实缺项，不是可以忽略的合规补课。 **收款就绪**：商户可以接受微信付款的状态。除基本进件通过、结算银行卡可用、延迟入账与自动结算已核实外，还必须已开通微信支付业务并完成微信实名认证与授权；未完成实名前不允许收款。 docs/adr/0001-merchant-onboarding-and-wechat-provisioning.md
@@ -3,3 +3,15 @@ 商户端一次提交进件资料与微信支付开通意图，平台在基本进件审核通过后继续开通微信支付。两阶段分别记录结果；基本进件成功而微信开通失败时，保留已通过的商户身份，仅重试失败的开通步骤，避免因支付配置失败重复进件。商户端展示审核、待实名、开通中及失败等阶段，不能用一个整体失败状态抹掉已完成的进件结果。 本地开发环境无法接收汇付回调，由商户端“刷新进度”和管理后台刷新主动查询审核及业务结果，并继续已满足前置条件的开通步骤。保留回调处理，不增加定时查询；没有回调且无人刷新时，进度会保持最后已知状态。这一取舍由用户明确选择，不能将它擅自改为后台自动轮询。 ## 2026-09-16 修订：分步推进、实名走法人、实名是收款前提 三处由用户明确选择。它们修订上文执行方式，不改变“进件与微信支付开通分别判定”这一根本判定。 **不做“一次进件即完成收款能力”。** 微信侧是多段异步外部流程：实名审核要等微信处理，中途可能有账户验证与签约，最后还有必须由人**扫描微信小程序码**完成的授权（`qrcode_data`／“授权二维码”，汇付在实名查询与业务开通异步通知里都会回传）。平台无法在提交那一刻把这些走完，硬做只会做出一个看起来完成、实际没生效的状态。因此收敛为：**进件一次收齐资料**，之后进件、微信业务开通、微信实名认证、延迟入账与自动结算按阶段推进；两端页面刷新查看，商户按阶段执行“下一步”。上文“由商户端刷新进度和管理后台刷新主动查询并继续开通步骤”的执行方式不变。 **微信实名认证走法人（`contact_type=LEGAL`）。** 实名申请使用法人信息发起，进件表单一次收齐所需材料，因此要新增**法人手机号**一项。不选经办人（`SUPER`）：它额外要求经办人身份证件正反面与**加盖公章的《微信业务办理授权函》**，盖章件无法自助提交。 **未完成微信实名认证与授权前，商户不允许收款。** “收款就绪”必须把微信支付业务开通与实名／授权纳入前提，不能只凭进件审核通过、结算银行卡与取现能力判定。这也意味着“等待实名”是收款能力的真实缺项，不是可以忽略的合规补课。 二维码展示不需要新做：商户端与后台详情页已经在渲染 `qrcode_data`。
