交易级严谨性：身份、终态、资金与执行权
日期：2026-09-29；状态：proposed，未锁定，不是生产实现或资金合规结论。 输入：一周无忧、本轮用户明确的订单终态不可逆要求。 编写及问题追踪：主会话；业务决策：用户；长期交易、履约、资金和运维负责人尚未指定，阻塞相应正式契约。
本文是本轮交易不变量和跨域协议的主讲位置；业务流程解释用户过程，状态定义解释独立生命周期。它们不改变 Runtime，也不把候选架构自动升级为已批准基线。
1. 严谨性要保护什么
不是把购物系统做成证券交易所，而是采用同等明确的事实边界：已发生的交易可追溯、终态不可逆、钱和货不重复、竞争只有一个裁决点、未知结果可核验。可用性下降可以暂缓受理，不能用猜测换取“流程成功”。
| 编号 | 不变量 | 权威保护处 | 能推翻设计的反例 |
|---|---|---|---|
| TI-01 | 订单取消、到期关闭、完成或处置关闭后，不再接受执行或回到非终态 | Commerce 状态迁移及 Fulfillment 执行门禁 | 重放付款成功事件使取消单重新开工 |
| TI-02 | 周计划、订单、资金、每日授权、现场执行是独立事实 | 各 Owner；组合查询保留来源 | 用一个“已安排”同时表示已付、同意和已送 |
| TI-03 | 一个明确购买意图只产生一次订单效果；合法新购买有新身份 | Commerce 来源守卫 | 两个不同请求幂等键对同一意图各造一单 |
| TI-04 | 同一份已购数量及同一资金切片不能重复用于旧单和替换单 | Commerce 分配守卫、Fulfillment 执行谱系守卫 | 旧单、新单各自版本正确却同时切配 |
| TI-05 | 无对应内容、时间、地址和费用的有效每日授权，不得订单级开工 | Demand 接受记录 + Fulfillment 门禁 | 只付款、只选时间、提醒送达即派工 |
| TI-06 | 确认与到期互斥；冻结与开工互斥 | 各自同一权威记录的条件提交 | 两服务先读相同状态再各自宣告成功 |
| TI-07 | 资金分配、消费、退款预留与退款成功满足守恒 | Commerce 原收款额度账 | 退款 UNKNOWN 释放额度后又退一次 |
| TI-08 | 成交、授权、实际执行及资金证据追加留存；更正不抹历史 | 对应事实 Owner | 覆盖订单行导致送货和退款无法解释 |
| TI-09 | 超时不是失败；技术重试不是新商业意图 | 流程 Owner / Channel | 响应丢失后换支付流水号再收款 |
| TI-10 | 页面、后台、定时器、补偿和重放共用门禁，管理员无通用改状态权 | Identity + 业务 Owner | 后台批量动作绕过终态或撤权 |
| TI-11 | 外部资金与物理事实只能补偿/更正，不能靠软件回滚抹除 | Commerce / Supply / Fulfillment / Finance | 数据库回档后再次退款、再次切肉 |
| TI-12 | 正常到期和结算自动推进；异常有时限、责任和恢复依据 | 各协调 Owner；Platform 提供执行机制 | 人工每天取消未确认单，或 UNKNOWN 永久无人处理 |
2. 对象、基数与唯一性
| 对象 | 所有者 / 身份 | 职责与基数 | 不承担什么 |
|---|---|---|---|
| WeeklyMealPlan / MealOccurrence | Customer；稳定餐次 ID + 编辑版本 | 周是视图；一日可多餐，一餐可多商品；保留历次购买引用 | 不是订单、订阅合同或钱包；编辑草稿不改变成交 |
| PurchaseBatch | Commerce；本次购买批次 ID | 用户接受的一次购买范围；包含多个独立订单，可跨日；补款和替换有明确关联 | 不以自然周强制关账；不能无限吸纳未来购买 |
| Order / OrderLine | Commerce；永久订单 ID、行 ID、来源意图 | 一次可独立处置的商业义务；一个批次多单，订单不跨配送日期和地址 | 独立确认时段拆分商业范围；合并配送不合并历史，部分商品处置细则待定 |
| ReplacementRequest | Commerce；替换请求 ID + 前驱订单/版本 | 记录旧单、新单、资金分配、停止回执与新授权；前驱不得有并行有效替换 | 不是旧订单的新状态版本，更不是恢复旧单 |
| DeliveryInstruction / ConfirmationRecord | Demand；安排 ID + 范围版本 / 不可变确认记录 ID | 明确哪些订单行、数量、地址、时段和费用由本次确认覆盖 | 不以用户+日期作为唯一键；不从付款推导同意 |
| ExecutionGate / FulfillmentOrder | Fulfillment；执行范围 ID + generation + revision | 控制该份数量是否可开工；拆包是分配不是复制；记录前驱停止证据 | 单个任务的锁不能代替谱系数量约束 |
| PaymentIntent / PaymentAttempt / PaymentTransaction | Commerce；收款目标 / 尝试 / 原渠道交易 ID | 一次目标可有技术尝试；一笔实收可分配多单；一单可含初款及补款 | 不强定付款与订单一对一；Receipt不是消息回执 |
| FundingAllocation / Refund | Commerce；原实收的金额切片 / 退款目标 ID | 每份金额有唯一去向和可核对变化；退款可按多个原交易拆分 | 不建通用充值余额，不静默跨周消费 |
| SettlementRun / SettlementRecord / Adjustment | Commerce；结算目标版本 / 已验证结果 / 更正 ID | 购买批次内核算；关闭后新经济事实另建关联调整 | 退款未核实不能宣告批次资金结清；对账执行不另造结算授权 |
身份须包含业务主体/商户范围；外部身份另含 Provider、渠道账号、对象类型。实际唯一键在共享模型收敛时定案，不以随机 UUID 或缓存幂等键替代业务约束。
建议来源关系：一次明确结算意图 + 被接受的购买范围确定初始订单来源；替换请求 + 前驱确定后继来源。餐次 ID 不永久唯一对应一单，否则合法重新购买会被误挡；同一购买意图不因换日期/重试就产生新身份。每个幂等键绑定主体、动作、目标和请求摘要：同键异载荷拒绝，同键同载荷返回原结果，过期缓存后仍查持久业务来源。
3. 订单终态与“继续服务”
订单终态不可逆，包括终态到另一终态也不改写原决定。售后、退款、补发、账务调整可以继续，但使用各自对象和关联，不把订单重新设为待配送。技术失败、协调暂停、资金未知不是业务终态。
- 未提交的餐次/购物车：原对象合法编辑，形成新版本。
- 已成交后换菜、改量：关联新单方案。原餐次身份保留；旧单合法取消并永久关闭，新订单重新接受报价和资金依据。未开始切配可申请，由冻结与开工竞争裁决；开工后进入实际处置/售后。费用和部分商品处置细则仍待定。
- 改联系方式、地址或时间：不一概重下单；只有契约明确允许、商业标的不变且未过执行边界时，追加受控修正记录和新安排。不能通用 PATCH 成交快照；影响每日授权即需新的明确授权。
- 到期关闭后又想买：新订单、新安排、新授权；原到期订单保留。能否复用未退资金，取决于分配守卫和批次政策，不以“恢复”绕过判断。
- 开工/交付后改变意愿：不走未执行取消捷径；保留实际数量与成本，进入售后或部分履约处置，不能假装没有发生。
不要求用户理解内部多张单。小程序仍可沿同一餐次展示“已更换”，详情可查原单、新单和差额；后台必须能查谱系和各自终点。
4. 每日确认与到期裁决
Demand 维护一份安排的权威接受决定；付款核验成功且订单成立后立即开放确认，允许提前确认未来多天；支付不替代同意，已确认不要求每日重复。确认必须绑定当前订单/行/数量、安排版本、地址、期望送达时刻、费用报价及用户明确同意。时段区间如何确定计费基准仍待政策，不能偷偷取起点或终点。
- 预览只读，不产生确认或扣费。正式提交重新鉴权、验版本和业务门禁。
- 如需配送费，Commerce 先建立独立费用目标并核验合法资金依据；收费成功仍不保证安排被接受。Demand 接受失败/到期后，由原目标恢复或补偿，不把晚到付款当授权。
- 在 Demand 本地裁决事务中，校验权威服务时间、政策版本、安排 revision 和合法资金依据，条件迁移并同时写确认记录与 Outbox。成功判据是权威提交，不是客户端点击、通知或 API 开始时间。 精确政策可以定义受理凭证，但必须有明确有效期，不能自动延长所有处理中请求。
- 到期任务对同一记录条件迁移；确认已成立则不再到期，未成立则到期后永久拒绝该安排的确认。默认截止配送当日北京时间16:00，可后台配置；权威接受严格早于截止，到期使用大于等于截止，边界已明确。详情及版本规则见确认政策。
- Demand到期后，Fulfillment保留不可执行证据，Commerce自动将对应open订单通过cancel转为cancelled并记录配送时间确认超时原因；Fulfillment 从未获有效执行授权，禁止开工。期间可展示“本次不配送·关单处理中”，不可伪称退款完成。鲜配同单使用同次完整范围确认；独立配送时间须拆开商业范围，不让同单部分accepted、部分pending后整单取消。合并配送的各订单仍独立授权；部分商品取消不借超时路径处理。
费用以期望送达时间提前满两小时（含边界）免费、不足两小时分档为已知规则；收费界限与自动取消截止是两套独立参数。消息延迟不改变已经原子接受的确认；核验未知结果回源，不由客户端补造接受时间。
5. 换菜与开工：跨域停止协议
协调 Owner 为 Commerce；每个 Owner 只提交自己的事实。建议安全优先协议如下，不宣称分布式原子回滚：
- 保存替换意图、原版本、目标报价和客户同意；在 Commerce 的前驱/数量守卫取得唯一替换权。预校验新规格、供给、可收费范围；预校验不等于放行。
- 请求 Fulfillment 冻结旧执行范围。
ready → frozen与ready → executing在同一 ExecutionGate 条件提交；未就绪范围也必须取得停止权。尚未生成任务也要创建永久停止墓碑，拒绝迟到的旧确认事件再造任务。 - 冻结先赢：所有待执行子任务受同一 generation/fence 约束，不得开工；确定没有执行中/未知现场动作后出具可停止证据。开工先赢：普通替换不得继续，按真实进展拒绝或另建售后处置。锁租约过期不证明现场停止。
- 确认停止后，Demand 撤销旧安排/授权，Commerce 关闭旧订单；各步骤回执持久化。冻结不是全链完成，旧单终态前须具备不可再次开工的证据。撤销传播不靠最终一致事件单独保证：旧执行 gate 已阻断，旧 epoch 永不再次被接受。
- Commerce 本地受控事务释放旧单合法可用分配、预留后继分配并登记来源；不能同时分配给退款。新订单仍不可执行。差价按新报价核算：例如可用原款30、新价38，补8；若原款已退款预留/已退/有争议，则不承诺只补8。便宜部分进入明确待结算款，不造钱包。
- 补款核验、新单商业接受、前驱永久停止及合法来源均满足后，新安排等待每日确认。已有新内容/时间/费用的明确同意可形成新确认记录，不能复制旧记录充数。过窗口则新安排也不得放行。
- 新执行范围引用前驱停止回执及资金/授权版本；在谱系分配守卫保护下取得唯一数量执行权。旧事件、旧任务、旧设备凭证均被 fence 拒绝。
失败恢复： 冻结前被拒绝时原单未改变，必须如实告知仍有效；正式冻结后不得静默解冻继续送旧菜。本方案冻结只走停止，若业务将来要求撤销变更后继续旧菜，必须另审授权及门禁协议。旧单已终态而新单失败时，只能补偿、核验或明确新建订单，不能逆转旧终态。已收补款先查原目标；UNKNOWN 保留资金占用并升级，不自动重复补款。
跨域期间允许“冻结中/替换中/待资金核验”，不允许新旧同时可执行。若设备不能在实际不可逆动作前在线验证 fence，须禁止其离线自主开工；仅写一条“有版本号”不足以证明物理防重。现场动作已发生但回执丢失时，隔离该执行范围、查证实物，不重派同份切配。
6. 资金守恒与自动结算
按每笔已验证实收、币种与业务主体独立记金额切片；整数最小货币单位，明确数量精度、舍入和优惠分摊政策，禁止浮点累计。Commerce 的运营资金账不替代 Finance 分录。
零应付订单须保存合法报价/优惠依据，不伪造一笔0元外部实收；足额资金门禁在其应付为0时可以成立，每日授权仍不可省略。外部渠道已收款是否可作为付款依据，须有独立验证契约，不能信任导入字段或客服勾选。
正常收款范围的核对式（无外部冲正时）：
实收 = 未分配可用 + 订单占用 + 已确认消费 + 退款预留 + 已退款
五项互斥、非负。争议冻结是所在切片的限制，不能另加一份余额；外部撤销/拒付须独立经济调整及对账，不能改旧实收金额使等式假平。可退依据来自取消/差额/售后裁决，不是公式中存在钱就任意可退。
| 操作 | 原子保护范围 | 不可做的事 |
|---|---|---|
| 购买/补款分配 | 原实收切片、目标订单范围、来源唯一性、分配账及 Outbox | 同一款同时归两个有效订单 |
| 替换重分配 | 前驱释放依据、新分配、并行替换/退款守卫；多收款按固定顺序锁定 | 把已消费或退款未知款当可用；先释放后异步无守卫再分配 |
| 确认消费 | 合法计价/称重/履约依据、对应分配及版本 | 单凭付款或 Job 完成记消费；称重超额直接再扣银行卡 |
| 退款受理 | 原交易可退额度、退款目标唯一性、预留及 Outbox | 多个退款各自锁自己却共用最后额度 |
| 退款结果 | 已验证外部目标、预留核销或确定失败后的受控释放 | 超时/查询无结果就释放；旧 UNKNOWN 和新退款并存 |
| 售后返还 | 合法裁决及原消费关联，追加消费调整再进入可退分配 | 因订单完成就拒绝所有售后；把订单改回未完成 |
退款政策重新待决：此前批次内暂留、范围结束统一退，与最新建议的确定可退后自动原路退，尚未完成取舍；不建立默认钱包或自动消费权。本段仅保护结算安全，不授权采用其中任何退款时点。“三天结束”不是第72小时无条件退款：要核实相关商业处置、实际计价、在途支付/退款和既有分配。正常已知结果自动处理；未知部分单独冻结追查，无争议部分如何提前退仍待政策。
按实际重量计价已确认；批次结束条件、超重处理、舍入、优惠及配送费分摊、退款时点仍须冻结后才能执行。结算目标必须绑定范围与依据版本；重复调度命中同一目标，不能每次新建退款。批次结清前核对所有必要退款结果；之后晚到事实建立关联 Adjustment/售后结算，不重开旧批次或重退整批。关单和退款完成可以异步，页面分别显示。
7. 消息、事务、外部结果与恢复
- 每次合法迁移把状态 revision、领域事实、必要额度变化、审计及 Outbox 同事务提交；约束写失败则全不成立。接收端把 Inbox/业务去重与自己的效果同事务提交。
- 不承诺端到端 exactly-once。至少一次投递 + 业务唯一性 + 核验补偿保护不重复效果。发送回执与实际效果分别存；持久状态是恢复点，不是队列消息。
- 消息含来源主体、聚合 ID/版本、事件 ID、业务操作 ID、因果及关联 ID、Schema 版本、发生/接收时间；不把敏感信息无差别灌进日志。
- 乱序旧事件不得覆盖新状态；缺中间事实时回源或挂起。合法重复返回原结果；未知动作/同键异载荷/终态迁移拒绝、无业务副作用并留审计。
- Payment/Refund/Channel 超时进 UNKNOWN，查询原目标和对账。支付协议适配归 Commerce，外部销售渠道适配归 Channel，不因都是外部调用而合并。再次发送必须满足原目标幂等能力与预算；Provider 无法防重复且结果未知时不得盲重发。已验证终态被迟到相反证据挑战时另立差异核验，不直接翻转终态。
- 调度重启按持久截止补扫；租约只防重复工作，不代替业务 CAS。队列积压、死信、在途未知均有可见年龄、截止和升级负责人；未指定数值/人员即未满足生产条件。
- 新人工动作执行时重新鉴权；恢复既有退款/清理义务使用独立受限服务主体，保留原发起者和实际执行者。客户登出或员工离职不能遗弃义务，恢复主体也不能借机新购或扩大退款。
8. 后台应支撑什么，而不是代改什么
| 业务工作台 | 必须查询的权威事实 | 允许的受控动作 | 禁止捷径 |
|---|---|---|---|
| 计划与明日配送 | 餐次、订单谱系、每日授权、截止政策、费用依据 | 提醒、解释；异常交接；配置经审核的新政策版本 | 替用户默认确认、修改过去的截止时间使已过期单复活 |
| 交易服务 | 旧/新单、不可变快照、替换步骤、停止回执、资金分配 | 请求合法取消/替换、核验原操作、按范围接手 | 通用状态下拉框、把订单设为已支付/已送达 |
| 履约工作台 | 授权范围、gate/generation、质量与物料、现场观察 | 受控停止、异常处置、核验现场 | 用重试按钮再做已完成切配，或人工解除终态 fence |
| 资金与对账 | 实收、可用、占用、消费、预留、实退、差异 | 查询渠道、符合裁决的补偿、职责分离的异常复核 | 人工勾选退款成功、清 UNKNOWN 后重新退 |
| 质量与售后 | 原消费、包裹/批次追溯、影响及分项回执 | 召回、补发新单、追加金额/物料更正 | 删除交付记录、直接恢复物料可用量 |
| 运营与审计 | 关联链、源版本、等待年龄、负责人、拒绝原因 | 有限范围重放、移交、查看前后证据 | Platform 直接改业务表或无限管理员兜底 |
人工只处理异常和政策需要的复核，不能成为每日履约常规步骤。批量动作逐项返回结果、版本和原因，不伪装跨订单全成功。读模型缺失要显示“待核验/来源不可用”，不能显示“未支付”诱发重复付款。
上述是业务支撑要求，不代表现有后台原型或服务已实现；页面检查与真实门禁测试必须分别验收。
9. 所有责任域的补充边界
| 领域 | 本轮必须落实的交易语义 | 仍需专项验证 |
|---|---|---|
| Identity | 对象范围、撤权、服务恢复主体、金额类职责分离；无终态 override | 撤权窗口、实际角色权限矩阵 |
| Customer | 餐次修订与订单谱系分离；地址簿/菜谱变更不回写成交 | 合并、注销、隐私与保留政策 |
| Catalog | 报价冻结引用规格；已发布内容修改不覆盖已购切法/单位 | SKU 失效时的新购拒绝与历史可读 |
| Supply | 质量门禁与物料额度原子接受；不可逆转换追加账；取消不凭空回库 | 多 Lot 并发、隔离与开工边界、实际退回验收 |
| Demand | 逐日授权不是订阅权益；确认/到期互斥；撤销有停止握手 | 时间政策、多餐拆并与服务承接 |
| Commerce | 终态、替换、原收款分配、退款/结算、售后独立 | 多账并发、称重差价、异常支付 |
| Fulfillment | generation/fence、谱系执行份额、现场未知不重复作业 | 离线设备、部分执行、交付证明与召回 |
| Finance | 经济源去重、平衡、期间门禁；更正新分录 | 授权重开会计期间是独立政策，不等于允许复活终态订单；不得借此改旧分录 |
| Channel | 外部销售渠道Provider/账号作用域、防伪验证、目标级幂等、未知核验 | 销售渠道观察与回传协议、晚到相反证据及退出时在途义务；真实支付适配协议归Commerce |
| Analytics | 分开计划金额、实收、消费、退款和净额；替换链不重复计履约 | 口径待定；重算只改派生视图，不触发退款/出货 |
10. 取舍、迁移与生产前门槛
取舍： 不选“整周一张万能单”，它把一天的取消扩散为整周；不选“付款后覆盖原单商品”，它抹掉经济承诺；不选“所有状态都严格线性”，因为资金与交付本就异步。采用独立状态机、局部强一致守卫、跨域显式协调，代价是存在处理中与补偿对象，但用户体验可沿餐次连续呈现。
迁移/回滚： 本轮无生产数据迁移。后续必须先盘点旧 ID、状态、资金、任务和未决消息；不明旧状态隔离核验，不强映为取消/成功。明确切换水位与唯一写入 Owner，兼容旧事件或拒收后转待处置；并行对账而非双写放行。软件回滚保留新事实与 fence，高版本已收款/已作业不能恢复旧数据库再执行。备份恢复后，在恢复对外写入前须与渠道实收/退款、现场作业核对。演练责任人和证据未定前不可发布。
待决门槛： 统一维护于定案条件。D-01至D-06影响商业规则；D-07至D-14约束运行责任、外部和现场契约、其他生命周期、范围、隐私与会计解释。未知不是 N/A；本页不另维护一份可独立关闭的待决清单。
完整审查库存、反证和本轮证据见审查报告。