# 一周无忧：从计划到交易，从授权到交付

> 2026-09-29；proposed。业务流程视图，不是另一套状态枚举。
> 上游：[业务意图](WEEKLY-CARE-PLAN.md)；主讲：[交易级严谨性](../08-domain-model/TRANSACTION-INTEGRITY.md)；精确候选迁移：[状态定义](../state/FRESH-DELIVERY.md)。

## 1. 先分清“生活安排”和“订单”

按周展示，按餐次编辑，按独立订单承担商业义务，按明确配送范围确认，按购买批次核算。周不是强制交易周期，日期也不是订单唯一键。餐次可以一直保留；一次订单取消、到期、完成后，**该订单永久结束**。重新购买或替换建立关联新单，而不是让原单回到待切配。

终态不可逆；订单按配送日和地址拆分，付款后可提前确认各次配送，无需每日重复。未切配可申请取消/换菜，实际重量计价已确定；资金去向、退费和计价细则仍待定。截止及配置见[确认政策](CONFIRMATION-POLICY.md)。

## 2. 入口、出口与日常流程

```mermaid
flowchart TD
    A[编辑餐次草稿] --> B[核对本次购买范围与报价]
    B --> C[创建购买批次及独立订单、付款目标]
    C --> D{验证原付款目标}
    D -->|未知| U[保留原目标查证，不重复收费]
    U --> D
    D -->|确定失败| F[未形成资金效果；原目标下合法新尝试或结束未成交意图]
    F -->|满足同目标尝试守卫| D
    F -->|明确结束且无在途效果| Z[结束本次请求，保留历史]
    D -->|实收成功但商业条件不成立| Y[阻断执行，核对原款及有依据的退回义务]
    Y --> S
    D -->|成功且商业条件成立| E[已付：可立即确认本次或未来配送]
    E -->|用户明确提交内容地址时间费用| G{Demand 同一安排权威裁决}
    E -->|持久截止任务| G
    G -->|合法接受| H[保存不可变确认记录]
    G -->|到期先成立| X[截止仍未确认：安排expired；自动停止并取消对应订单]
    G -->|条件不符| K[拒绝或核验原请求；不宣告已确认]
    K -->|仍待确认且窗口有效| E
    K -->|已存在结果| I[读取权威结果；按原协调进度继续，不重复执行]
    H --> J{Fulfillment 执行门禁}
    J -->|取得唯一执行权| L[切配称重封装交付，逐项保留实际证据]
    J -->|不能放行| Q[有责任和时限的异常核验；不猜测重做]
    Q -->|仍处允许执行状态且条件重新满足| J
    Q -->|停止及商业处置已核实| N
    L --> N[核实完整交付或异常处置，商业订单进入对应终态]
    X --> S[按待定结算政策核对实际应收、原款和待退金额]
    N --> S
    S --> T[按获批资金政策处理应退款；政策未定不执行]
    T --> V{必要资金结果全部核实}
    V -->|是| W[购买批次结清]
    V -->|否| R[原目标查证与受控补偿；未决部分继续可见]
    R -->|取得新证据| V
```

这张图表示流程协调，不新增状态迁移。回到核验/门禁节点不是将状态回滚：已冻结、已开工或终态对象只能沿各自机器合法出边推进。I是读取并回接原有协调实例，不新建一轮履约；旧请求已被拒绝也不自动代用户提交新同意。Z要求没有在途外部效果；存在UNKNOWN不能走此出口。

S表示分项资金核验及持久结算责任；各分项退款是否先于整批结束由D-05决定，图示不施加整批等待门禁。只有整批结清才须等待范围稳定、其他必要义务及计价依据，不能把某单结束直接当整批结清。Y中的不成立交易与原款仍须独立核对，不能把没有成立的订单伪造为已消费。具体资金去向与退回时点遵循D-05；该项未定，不授权采用图中任何默认退款时点。

## 3. 每个门禁由谁负责

| 门禁 | 权威判定 | 不满足时 |
| --- | --- | --- |
| 买什么、多少钱 | Commerce 接受报价；Catalog 提供规格版本 | 不覆盖已接受价格，不伪造付款成功 |
| 钱是否可用 | Commerce 验证原款、分配、补款及退款预留 | 查原目标，不能重复收/退或把未知额再次抵扣 |
| 这次是否送 | Demand 确认/到期同记录竞争；用户明确同意本范围 | 不确认不送；选时、提醒、付款不等于同意 |
| 是否能开工 | Fulfillment 同 gate 裁决冻结/开工；质量由 Supply 判断 | 阻断且有责任人，不能用后台按钮跳过 |
| 能否换菜 | Commerce 协调，先核验旧执行停止及资金来源 | 旧单已终态不恢复；新单未成立如实显示处理中 |
| 能否结算退款 | Commerce 核对实际应收及原款；Finance 解释经济事实 | 分开确定与未知部分，不把未送写成已退 |

提前满两小时免费是费用分界，不是到期关单线。确认开放于付款核验且订单成立，默认截止配送当日北京时间16:00；严格在截止前权威接受，等于或之后拒绝。已确认不在16:00取消。截止可配置，具体费用档位仍待定。定时任务重启补扫，不依赖用户打开小程序。

## 4. 后天换一道菜：用户不重走整周，底层不篡改原单

例如原单30元换为38元：

1. 编辑餐次草稿并不取消原单。正式提交时说明旧安排是否仍有效、新价和新范围。
2. Commerce 取得前驱的唯一替换权，Fulfillment 冻结与开工竞争。若开工先成立，普通替换拒绝并说明实际进展；不能强行换单掩盖已切配事实。
3. 冻结成功后核实停止，Demand 撤销旧安排，Commerce 关闭旧单。旧单永久保持终态，旧任务凭证永远不能开工。
4. 以替换请求关联新订单和原餐次。原30元若仍合法可用，则受控重分配并补8元；已退/退款未知/已消费的部分不能再用。
5. 新内容、时间、地址及费用须有明确新授权，才可配送。可以在“更换并按此安排配送”一次表达同意，不机械要求多点一次，但不能继承旧确认充数。
6. 旧单已结束后新单失败：核验、补偿或明确新建，不恢复旧单。未生效新单不宣告已换；冻结后的旧菜不能静默继续配送。

更便宜的差额进入有来源的待结算分配，不默认充值钱包。已经到期关闭后再买，同样使用新单/新安排；可否沿用原批次未退资金，仍按政策和额度判断。

## 5. 后台接手点与用户可见结果

正常确认、到期停送、关单和批次核算由系统自动完成，不要求人工每天点取消/退费。后台处理结果未知、停止回执缺失、物料异常、争议与差异，不代替顾客确认。

用户看到连续的餐次，后台能追溯每个独立对象：原/新订单、购买批次、授权、执行范围、实际数量、原实收、退款及结算。关单处理中、退款处理中各自如实展示；不会因一天未确认删除其他天，也不会因一笔退款未知重收整周。

## 6. 待决和验证

未决事项统一见[定案条件](../DECISIONS.md)，本流程不另设日期、费用或取消权利。不可从原型预填数字反推业务批准。

本轮已把六类候选机器放在单一可读定义中；结构检查不证明真实资金、数据库竞争或物理防重。完整反例和剩余缺口见[审查报告](../../reports/review/ARCH-2026-09-29-transaction-integrity.md)，不宣称产品验证通过。

## 7. 异常不是终点：出口与恢复责任

下表是对既有协议的出口核对，不定义另一套状态。恢复调用原Owner的合法命令，不由客服、定时器或浏览器改多个领域状态。

| 情景与已发生事实 | 必须保留的边界 | 恢复负责人及动作 | 结束证据；未结束时保留什么 |
| --- | --- | --- | --- |
| 报价过期、范围或授权无效，尚无副作用 | 拒绝本次请求；不自动接受新价或扩大范围 | Commerce返回原因与当前可重新选择的上下文 | 本请求确定拒绝；用户如愿购买，另行明确提交 |
| 支付明确失败，未产生实收 | 失败尝试不可改回执行中；新尝试仍受原目标唯一性守卫 | Commerce判断目标是否仍有效，并核对其他在途尝试 | 合法重试完成，或结束未成交请求；无UNKNOWN才可按未付处理 |
| 收款响应丢失、到账观察不完整 | 原目标未决，不再次收同一笔 | Commerce查询原渠道目标、对账验真 | 验证到账或确定失败；查无结果不自动等于失败 |
| 钱已收，但订单接受失败/已到期取消 | 款项真实存在；不复活终态订单，不自动转新购 | Commerce将实收与失败目标关联，确定无重复分配，建立有来源的退回/结算义务 | 必要退款核实或合法分配完成；不能留一笔无主实收 |
| 费用已收，但每日确认输给到期 | 付款不构成配送授权，安排保持到期 | Demand返回确定裁决；Commerce核对费用目标并执行适用补偿 | 费用处置证据核实；不把商品整周付款误退 |
| 确认响应丢失或重复提交 | 不发第二份授权，不创建第二份数量 | Demand按原操作、安排和版本回源 | 返回已有确定结果；源不可用继续待核验 |
| 到期任务宕机、重复或迟到 | 任务没跑不等于默认同意；用户无需打开应用 | Demand按持久截止补扫；Commerce恢复对应关单步骤 | 安排终止及相关范围商业处置；资金单独继续 |
| 停止请求超时或设备失联 | 请求停止不等于已停止；不能放行替换单 | Fulfillment隔离范围、查原任务与现场，Commerce保留替换进度 | 永久停止证据，或真实已执行/部分执行处置；不得猜测重做 |
| 旧单已关闭，新单或补款未完成 | 旧单不复活；新单不宣告生效；已收款不遗失 | Commerce按ReplacementRequest持久步骤查证、继续合法后继或补偿 | 后继成立，或后继不存在/已停止且必要补偿全部验证 |
| 部分切配、缺货、拒收或部分交付 | 不伪写全额已送，也不把物料自动回库 | Fulfillment保存分项实际，Supply处理实物，Commerce裁决应收及售后 | 商业处置、物料处理及资金各有证据；精确部分处置合同受D-02/03/04/10约束 |
| 退款超时或对账不匹配 | UNKNOWN继续占用原款额度 | Commerce查原退款目标；差异独立调查，Finance解释已验证经济变化 | 必要退款全部验证才结清；无争议部分政策未定不擅退 |
| 批次结清后出现售后、拒付或迟到相反事实 | 原终态和原记录保留 | Commerce建立关联Adjustment/售后，Finance追加更正 | 新义务独立核实；不重开整批重退，精确调整合同仍需D-10 |
| 员工撤权、交接未接收或通知失败 | 原义务不消失；新人工动作重新鉴权 | 对应Owner的受限恢复主体继续；主管接管工作责任 | 源业务结果及合法接管证据；“已分派”不当业务终点 |

每项未决必须保存源对象、原请求、已成功步骤、剩余义务、等待起点、下一合法动作与责任。D-07尚未确定的数值和实际人员不能写成已部署保障。表中明确标出的D-02/03/04/10缺口意味着相关精确合同仍未闭合，不用“受控处置”四个字掩盖。