# 一周鲜配：独立状态机与裁决约束

> 状态：proposed；2026-09-29；未锁定，不是 API/数据库生产枚举。
> 维护：主会话；正式长期 Owner 待指定。没有关联已锁定 REQ。

## 1. 唯一迁移来源与适用范围

[fresh-delivery-machines.json](fresh-delivery-machines.json)是本轮六类候选对象的唯一机器可读迁移定义。它定义订单、每日安排、执行门禁、资金操作、替换流程和购买批次；**不是项目 Loop 的状态机**，也不是全部商品、质量、售后、账务和设备生命周期的完成清单。

定义包含每个持久状态的含义、恢复动作、超时政策占位、Owner、初态、终态，以及 `from/event/to/guard/effect` 迁移表。guard 为语义契约标识，尚无生产实现；不能因为模型可运行就宣称真实鉴权、支付、并发或物理门禁已通过。

业务主讲：[交易级严谨性](../08-domain-model/TRANSACTION-INTEGRITY.md)。本页不再定义另一套枚举。查看由定义直接输出的完整转换表：

```bash
node docs/architecture/state/verify-fresh-delivery.mjs --table
node docs/architecture/state/verify-fresh-delivery.mjs
node docs/architecture/state/verify-confirmation-policy.mjs
```

## 2. 六条事实线怎样协作

业务机制由[确认政策](../05-domain/CONFIRMATION-POLICY.md)主讲，JSON同步其结构化表达并唯一维护迁移；默认值不是反向制定业务政策的依据。`order.expire`的guard明确排除配送时间确认超时，避免与`order.cancel`形成同一原因的两条商业终点；其他商业过期政策未定义时不放行该路径。

`purchase_batch`描述汇总结清，不拥有全部退款的发起资格。独立Refund按其来源与政策运行，不要求所有退款都先使批次进入refunding；汇总结清仍须核对已发生与在途退款，具体时点/去向按D-05定案。

```mermaid
flowchart LR
    P[Customer 餐次意图] --> B[Commerce 购买批次]
    B --> O[Commerce 独立订单]
    M[Commerce 原交易资金与分配] --> O
    O --> D[Demand 每日确认安排]
    D -->|授权范围与版本| G[Fulfillment 执行门禁]
    O -->|商业条件与停止协议| G
    G -->|实际执行证据| S[Commerce 结算与退款]
    M --> S
    R[Commerce 替换协调] -->|停止前驱后建立后继| O
    R -->|冻结与开工争用同一门禁| G
```

这是协作图，不是把六机合并的一张状态图。订单 `open` 不意味着可以开工；替换 `completed` 不意味着新单已每日确认；批次 `closed` 不禁止独立售后，但禁止重开原结算。资金操作适用于一次可能产生外部效果的操作记录，稳定业务目标与技术尝试另有身份：已验证失败的尝试不复活，新的合法尝试仍受同一目标/原款额度守卫约束。

## 3. 所有迁移的公共前置条件

- 主体已认证且对象范围、动作、金额权限有效；用户/服务/外部观察分别识别。
- `expected_revision` 匹配、操作身份稳定、同键载荷一致，没有冲突的已提交效果。
- JSON 中对应 guard 完整通过；检查是无副作用的，资源校验与写入在同一 Owner 的受保护提交中完成。
- 原子提交新 revision、事实、必要额度、审计和 Outbox；外部动作只能发生在持久意图之后。
- 同一成功操作重复提交返回原回执，不把它当新的合法迁移；终态可查询，可追加关联证据，但没有出边。无定义事件、失败门禁拒绝且不修改业务事实，保留拒绝审计。

### guard 与依据责任

| 定义中的语义族 | 执行 Owner / 权威证据 | 原子边界或协议 | 未决限制 |
| --- | --- | --- | --- |
| order 接受/关闭 | Commerce；报价、经验证分配、停止/交付回执 | 订单版本、来源与额度；不在读模型上判终态 | 未切配可申请取消；确认超时对应cancelled；部分处置及费用待政策 |
| instruction 确认/到期 | Demand；用户同意、范围、权威时间、费用资金凭据 | 同一安排 revision；时间谓词必须互斥完备 | 付款核验且订单成立后开放；默认配送日北京时间16:00，t<截止接受、t>=截止到期；费用档位待定 |
| instruction 撤销/关闭 | Demand；Fulfillment 永久停止或实际结果 | 先停止握手再承认撤销；请求停止本身不证明停止 | 执行后处置不冒充未确认到期 |
| gate 放行/开工/冻结 | Fulfillment；前驱终止、分配、授权、Supply 门禁 | 同一 gate + 数量谱系 + fence；现场动作前核验 | 质量跨域撤销及设备执行协议待合同 |
| money 派发/判定 | Commerce；其支付适配器验真后的同目标结果 | 原款额度与派发意图；未知保留占用 | 实际 Provider 幂等和确定失败定义待核实；Channel 不包办支付接入 |
| replacement 取得权利/关闭旧单 | Commerce；前驱唯一替换守卫及永久停止回执 | 多步骤保存回执，不假设跨 BC 一次事务 | 开工先赢时普通替换拒绝，不强行关旧单 |
| replacement 后继/补偿 | Commerce；资金分配、后继来源及受控关闭结果 | 新旧数量不能双用；补偿验证后才到终点 | 报价/补款有效期和补偿时限待定 |
| batch 结算/关闭 | Commerce；稳定范围、实际计价、无未知款和必要退款结果 | 批次结算与替换入口互斥，原交易退款额度守卫 | 无争议分项可先推进，整批关闭仍需全部收敛 |

表达式中 `UNRESOLVED` 不是无限期许可。每个非终态必须在政策冻结时有等待期限、补扫/查证动作、升级条件和真实接手人；不得用统一技术超时把未知强制变终态。

门禁范围须精确：初次购买没有前驱，仅替换单要求前驱永久停止证据，不能使初始订单永远无法放行；旧安排结束可以是未确认撤销、到期或已接受后安全撤销，不能强制所有旧安排都经历 accepted；补偿时后继可能尚未建立，须证实其不存在或已永久停止，不能伪造一张已停止后继。`successor_absent_or_stopped_and_all_required_compensations_verified` 表示“（后继不存在或已停止）且所有必要补偿已核实”，不是不存在后继就免核对资金。

## 4. 竞争、拒绝与恢复

| 场景 | 线性化点 / 应有结果 | 失败或断点恢复 |
| --- | --- | --- |
| 同版本确认 vs 到期 | Demand 同一记录 CAS 只提交一个；时间政策进一步决定是否有资格竞争 | 响应丢失查原请求；晚到钱不复活安排 |
| 冻结 vs 开工 | Fulfillment 同一 gate CAS；子任务/设备必须受 fence | 冻结赢则不能开工；开工赢则查实际，不用普通替换强制覆盖 |
| 多个不同键替换同一旧单 | Commerce 前驱+可替换数量守卫 | 返回已有冲突请求；新订单 ID 不能绕过谱系守卫 |
| 退款 vs 重分配 | Commerce 同一原收款额度集合受保护提交 | 失败全不成立；UNKNOWN 款继续占用 |
| 到期/确认事件重复或乱序 | 回源版本、业务身份及永久停止墓碑 | 不再造旧任务，不重新扣/退；缺事件查源 |
| 网络发送后进程宕机 | 发送前已有 in_flight 持久意图 | 查询原目标；不能当未发送再造新目标 |
| 切配发生但证据丢失 | executing 保持未决，不回到 ready | 隔离、核实现场，再提交事实；不得重新切一份 |
| 最后一日结束 vs 后继创建 | 批次关闭范围版本与变更准入守卫 | 结算中不偷偷加新单；需等待或另行明确购买 |
| 终态后相反外部证据 | 原终态不改变，保留新观察并建立差异/调整 | 查询权威来源、补偿或新单；不能丢弃证据也不能直接翻转 |

冻结后的旧 gate 无解冻出边，这是当前安全优先取舍，不是遗漏“重试”；新的明确服务意图使用新对象。`revoking`/`executing` 的异常可以等待核验，不强行转 `stopped`；真实部分完成走有实际证据的 `resolved`，不能按完整交付结算。

## 5. 审计、指标和迁移

每次接受或拒绝至少关联：主体/原发起者/实际执行者、业务范围、对象和前后版本、事件与操作 ID、请求摘要、因果链、政策与门禁依据、发生/接收/裁决时间、回执及拒绝原因。敏感证据另存受控引用；禁止把完整支付凭据暴露在工作索引。

监控：各非终态停留年龄和超过政策时限数、到期补扫延迟、UNKNOWN 金额及年龄、无负责人异常数、重复效果被拦截数、终态迁移拒绝、旧 fence 拒绝、资金/数量对账差额、Outbox/Inbox 积压、原型投影与源事实延迟。阈值及值班负责人未指定，仍是上线缺口。

机器升级必须提供旧版本状态映射、未决操作迁移、事件兼容和回滚读取路径；不能把未识别状态默认为初态。恢复备份后先核验外部资金/实物与源去重，再放开写入；回滚软件不回滚已发生事实。

## 6. 验证边界

本轮业务机制见[确认政策](../05-domain/CONFIRMATION-POLICY.md)。JSON的confirmation_policy与guard_semantics记录默认16:00、可配置、严格截止、付款后提前确认、无需每日重确认及超时原因；没有增加第二套迁移。`pending → expired`通知Commerce走`open → cancelled`；order.expired不是本路径的另一种可选结果。历史模型尚未投入产品，正式迁移仍须识别老终态，不为统一展示改写旧订单。

新增确认政策探针读取同一JSON迁移，验证提前确认、截止相等、已确认保护、补扫、部分确认和配置快照。布尔条件及内存快照仅表示候选门禁，不证明真实数据库权威时间、跨服务停止或资金安全。

随附脚本只检查候选定义结构、可达性、单事件确定性、终态无出边、全部声明迁移、门禁拒绝、旧 revision 拒绝、串行化竞争模型和故意损坏定义的拒绝。它使用布尔门禁模型，**没有实现业务 guard，也没有证明数据库并发、跨域恢复、资金守恒或真实支付安全**。

资金、质量、现场、权限、迁移和后台端到端反例见[审查报告](../../reports/review/ARCH-2026-09-29-transaction-integrity.md)。缺产品证据的项目仍为未验证，不记 N/A 或 PASS。六机定义须政策收敛与正式评审后才能进入生产模型/合同；其余对象的状态机仍需设计。