跨域业务逻辑关联论证 v1.1

版本：v1.1 ｜ 日期：2026-09-01 ｜ 起草：小齐 ｜ 状态：已拍板生效（缺口 G1-G4 全部关闭，拍板口径见 §七）

v1.0→v1.1：G-1 口径落定（福钥=商户预付已耗，不退回额度，与余量阈值联动）；G-2 白名单两类；G-3/G-4 按建议处置。

触发：刘总 2026-09-01 指令——「很多业务逻辑和关联的事项也需要论证设计」。

问题：六条主链的每一段都单独验收过，但链与链的接缝从未做端到端论证。本文档以链路为单位补上这一层，作为后续施工/联调的验收锚点母本。

引用基线：订单域契约 v1.0（WIP-056）、订单域详设 v1.1、钥匙锚定 v0.8.2、争议规则 v1.1、双轨决议 v1.0、分销 v2.2、反向定制 v1.1a。

本文只论证已定结构的接缝；各链内部细节以源文档为准，冲突时以源文档为最高准。

链一：下单链（类别查重 → 拆单 → 双轨 → 福钥冻结 → 发码）

数据流：游客提交订单 → precheck 类别查重（刘总 23:44 口径：已有有效订单含该类别→提醒可继续；不含→不提醒；有效=status ∈ booked/paid/confirmed/in_service/partially_redeemed）→ 按商户拆单生成 batch_no（码边界=一次下单动作）→ 1P 轨走平台商户号线上收款/3P 轨线下直结双钥匙判定 → 福钥按分笔冻结 → 核销码生成（一码对全单）→ 站内信 N1。

接缝论证：

1. 查重→拆单时序：查重在前端提交前，拆单在后端事务内——查重结果不阻塞下单（只提醒），拆单不可逆（batch_no 恒定）。两动作之间游客可能并行提交第二单，查重以提交时刻快照为准，接受这个竞态（提醒非闸门，重复类别可继续是拍板语义）。
2. 双轨→福钥冻结：跨主体组合（1P+3P 混单）永久不设平台统一收款——拆单后每子单独立判轨；福钥冻结只发生在平台记账部分（3P 线下直结的券款不冻结福钥？不——福钥冻结锚定的是履约凭证不是收款轨：3P 单福钥同样冻结、核销后同样解冻分账。此处以契约 v1.0 §二为准：冻结与轨无关，与履约状态机有关）。
3. 一码一提交：同 batch 下所有子订单共享一个码；码的 pending 态在所有子订单退回可核销态时才恢复。

断点风险：拆单事务中商户侧支付网关超时→batch 半成立；处置=子单独立状态机推进（draft→booked 失败不影响已成立子单），N2 逐商户通知。

验收锚点：跨主体组合单实测四条件展示；查重提醒对五状态集合的边界（cancelled 不提醒）；福钥冻结分笔与子单一一对应。

链二：核销链（扫码 → 身份路由 → 幂等核销 → 部分完成 → 7 日确认）

数据流：商户员工扫游客码 → 身份路由（merchant_staff 七角色，owner/manager/cashier 可核销）→ 子订单状态校验（confirmed/in_service/partially_redeemed 才可核销，pending_confirmation 不允许提前）→ 幂等写入 redemption_events（唯一索引防重复提交）→ 子订单推进（partially_redeemed→completed，batch 内全部完成→批次 completed）→ N3（游客）+N4（同 batch 其他商户可见进度）→ 游客 7 日确认窗口（第 5 天 N7 提醒，超时自动确认）→ 游客可异议（N8→客服流程，不进 redemption_conflicts 技术冲突队列）。

接缝论证：

1. 幂等与部分核销：唯一索引在（订单行×核销事件）粒度——同码重复扫不重复记账；部分核销=部分行完成。与撤销链交叉：24h 内商户可撤销单笔核销（事件→revoked→福钥解冻回游客→分笔逆账→码状态回退）。
2. 技术冲突 vs 业务异议分轨：redemption_conflicts 只收技术冲突（离线补录与在线记录打架等）；游客异议走客服/争议流程。两队列禁串（契约 §4 明示）。
3. 离线三级（核销员手册参照+作战手册）：无网=纸质台账登记→复工补录（channel='offline_manual'+offlineRef）→N6 告知游客。断点：补录与游客先行异议的时间窗竞态——处置=补录事件带时间戳凭证，异议窗口从补录完成时起算。

断点风险：码 pending 回退条件判断错误（无其他有效事件时才回 pending）→幽灵码；24h 撤销窗与 7 日确认窗重叠区（撤销发生在游客已确认后）→以事件时间戳裁决，撤销优先但通知 N5。

验收锚点：重复扫码幂等实测；部分核销状态推进 grep 状态机五值零越界；离线补录→N6 全链路 staging 实测。

链三：账单链（核销事件 → 账单生成 → 7 日确认/争议 → 自动落账）

数据流：redemption_events 聚合 → 月度账单生成（四类金额：服务费/核销补贴/调整项/合计）→ N9 通知商户 → 商户 7 日内确认或争议（dispute 只冻结争议行，无争议部分照付——争议规则 v1.1）→ 超时自动 auto_confirmed + N11 → 平台收入=服务费单轨（保证金已废止，零垫付零押品）。

接缝论证：

1. 核销→账单的口径一致性：账单聚合源=redemption_events（含 offline_manual 补录与 revoked 逆账）——撤销事件必须双写（核销链写入事件，账单链按事件净额计算），否则 24h 撤销窗内的已生成账单会多计。处置=账单生成时点后发生的撤销走下期调整项，账单内金额以生成时点事件快照为准。
2. 争议→额度侧三连：账单争议（N10→运营）与商户违约执行（欠账挂账→扣福钥可发额度+限营销→逾期清退）是两个域的接缝——争议未决不触发三连，三连只对已确认欠账执行；扣「可发额度」不动已发放福钥（游客侧不受商户违约影响）。
3. 服务费定价口径：固定档位月付（¥300/¥1200/¥3800 待拍板），禁按 GMV 百分比（旅行社证红线）——账单域代码中服务费计算不得存在 percentage 抽成路径。

断点风险：自动落账定时任务（7 日）与人工争议并发——锁账单行；跨月撤销（见上，调整项）。

验收锚点：四类金额与事件净额逐笔对账脚本；争议行冻结/无争议行照付实测；三连触发与争议未决互斥实测。

链四：福钥链（发 → 冻 → 赚 → 花 → 退）

数据流：发=商户签协议交服务费时平台赠送（唯一产出通道，定性=不可兑换补贴凭证）→ 冻=下单冻结分笔（credit_journal 记账）→ 核销完成解冻 → 花=游客在 3P 商户处抵扣（线下直结场景）→ 退=撤销/取消逆账回余额。

接缝论证：

1. 福钥与钱的双严隔离：福钥永不兑换现金（K23 红线）；商户侧福钥价值由「核销补贴=唯一现金出水口」回收——补贴发放以核销事件为唯一触发（防：无核销发补贴）。信用账本 direction/amount/biz_type/ref_id 四列结构（PLAN-08 陷阱表实证过的口径）。
2. 退款链接口（已锁定规则）：3P 线下订单禁平台退款、7 天无理由硬拒、退款钥匙回余额（非冻结池）——退款是订单域动作+福钥域逆账的跨域事务；回余额=立即可用，与冻结池语义严格区分。
3. 商户违约扣的是「可发额度」不是「已发福钥」：清退商户的未核销福钥游客侧处置——已拍板（2026-09-01 刘总）：口径=「发出去的福钥就是花出去的钱，只是商户提前把钱给到了平台」——已发放未核销福钥视为商户已消耗的预付成本，不退回商户可发额度；游客侧处置须与商户福钥余量阈值联动（余量即商户行为界定：欠账挂账→扣可发额度→限营销→清退，零保证金下的替代约束）。处置细则由小齐按此口径出方案（原缺口 G-1 关闭）。

断点风险：冻结/解冻与订单状态机不同步（订单 cancelled 但福钥仍冻）——对账脚本每日跑冻结净额=在途订单应收冻结额。

验收锚点：credit_journal 每笔可溯（ref_id 指向订单/事件）；退款回余额实测；G-1 已拍板（口径见上）。

链五：通知链（N1-N12 触发点 → app_messages → 电话兜底 SOP）

数据流：业务事件（下单/确认/核销/撤销/补录/确认提醒/异议/账单三态/裁决）→ 触发点写 app_messages → 游客/商户/运营三方按矩阵投递 → 关键节点（24h 确认超时类）电话兜底=线下 SOP。

接缝论证：

1. 触发点规范已定（契约 §六矩阵）：每张派工单凡涉及状态变更必须对照矩阵核触发点——这是前端接管订单域联调的高频坑点（状态推进了信没发=接缝断）。
2. N17 品类订阅（需求广场域）与 N4（batch 进度）共享商户工作台消息通道——N17 落地时须复用 app_messages 管线，禁另建通知轨。
3. 全量站内信不用微信订阅消息（既定）：降级路径只有电话兜底——兜底名单已拍板（2026-09-01）：仅「确认超时将取消」「争议裁决」两类事件够格电话兜底，其余一律站内信（原缺口 G-2 关闭）。

验收锚点：状态机每个转移边与 N 矩阵一一对照的覆盖表（联调时逐边打勾）；app_messages 落库与页面展示时延实测。

链六：需求链（心愿单 → 需求发布 → 广场展示 → 分项响应）

数据流：游客自组清单（跨商户意向卡，不出总价）→ 发布需求（open 态入广场）→ 广场按品类展示（禁匹配排序/禁抢单竞价/禁闭环成交/禁联系方式裸奔）→ 商户/向导分项表达兴趣（响应颗粒度=分项响应、禁整单承接）→ 过期退出广场（open→expired，我的需求仍可见，可续期 7 天）→ N17 品类订阅推送给订阅商户。

接缝论证：

1. 定性分界在平台行为不在介质（v1.2 拍板）：页面只是展示，红线约束的是平台动作——搜索/列表接口禁按匹配度排序（按时间即可）、禁提供抢单按钮、成交引导到线下自证。此定性是需求广场全部接口设计的验收母法。
2. 需求→订单的「不转化」设计：需求广场刻意不与订单域打通（禁闭环成交）——兴趣回应后线下自行成交，若商户把需求转为正式商品交易，走正常下单链（链一），与需求记录互不引用。这是合规防火墙，不是功能缺失。
3. 整包承接留给 W2 持证合作公司：向导个体户只表达兴趣——与分销 v2.2 §8.8 向导四不（不报价不撮合不收款不担保）同一条合规线的两个面。

断点风险：需求含违禁联系方式文本（裸奔禁令）——发布时文本过滤（手机号正则等）；过期判定与续期竞态。

验收锚点：排序接口无匹配度字段；响应记录无价格承诺字段；过期需求不出广场实测。

七、缺口清单（本次论证发现，2026-09-01 刘总全部拍板关闭）

八、本文档用法

1. 每张涉及跨域的派工单，硬约束模板须引用对应链的「验收锚点」；
2. 联调阶段按链推进（链一→二→三为交易主干序），每链闭环=PLAN-03 的阶段验收单位；
3. 缺口清单随拍板逐项关闭并回填《项目总纲》决议索引。