# 鲜配确认：付款后开放，配送当日16:00截止

> 2026-09-29 · 本轮用户明确决定的机制及其架构约束。不是产品已实现或REQ已锁定的证明。
> 上游：[一周无忧](WEEKLY-CARE-PLAN.md)；状态唯一来源：[鲜配状态定义](../state/FRESH-DELIVERY.md)。

## 1. 已决定的事实

| ID | 决定 | 适用边界 |
| --- | --- | --- |
| CP-01 | 一次付款可覆盖多个订单；订单不跨配送日期和地址 | 同日多次购买仍可多单，不按用户+日期去重；合并配送不合并商业历史 |
| CP-02 | 未开始切配可申请取消/换菜；停止与开工由系统竞争裁决 | 申请不保证取消成功；开工先成立则走实际处置/售后。费用细则尚未定案 |
| CP-03 | 商品按实际重量计价 | 超重处理、舍入、优惠和费用分摊仍待D-04；不据此取得额外自动扣款授权 |
| CP-04 | 付款核验成功且订单成立后，立即允许明确选择并确认配送时间 | 可以顺手确认未来多天，无需等前一天或每天重新登录；付款本身不是确认 |
| CP-05 | 默认在配送当日北京时间16:00截止确认，后台可配置 | 服务端权威裁决时刻严格早于截止才可接受；等于或晚于截止均不接受 |
| CP-06 | 到截止仍未确认，系统自动取消对应订单和安排 | 已提前确认的安排不取消、不要求重复确认；资金处理独立 |
| CP-07 | 未确认到期的服务结果显示“未正常履约”，注明确认超时原因 | 不误记为商家配送违约；未完成后台关单时如实显示取消处理中 |

这里的“逐日”指每个配送日各自有授权，不是每天必须回来点一次。**未确认：无操作自动取消；已确认：无操作正常配送。** 已确认后临时不需要，必须主动申请取消，遵守切配边界。前晚确认明日订单、次晨备货可正常承接；员工下班不阻断合法隔日确认。

## 2. 确认窗口与当日承接

每个安排持久保存业务配送日期、时区、政策版本和绝对截止时刻。本页已确认的默认时间为Asia/Shanghai、16:00，不依赖用户设备时区；[状态定义的confirmation_policy](../state/fresh-delivery-machines.json)同步表达该机制，不独立决定业务政策。

- 开放条件：订单已被商业接受、原付款核验成功（合法零应付使用已验证零应付依据），本次商品/地址/时间/费用版本及明确同意齐全。
- 时间条件：权威裁决时间 `t < confirmation_deadline`。截止任务使用 `t >= confirmation_deadline`，且只作用于pending。
- 时段条件：所选送达时间属于可服务范围，并仍有足够准备和配送时间。16:00不是最后送达时间，也不保证15:59能接受任意时段。
- 一直没有选择时段，也有配送日统一截止；不能因缺时段而无限等待。某早时段已不可选时，可在统一截止前选择其他合法时段，不仅因预览了早时段就提前取消整个订单。
- 当天截止后，不为新的当天意图收取明知无法确认的款；引导选择其他可承接日期。预检后跨过截止的在途付款，仍按原目标查证和有依据的资金处置，不能强行确认。
- 配送费按期望送达时刻距有效确认时刻计算：提前至少120分钟免费，不足120分钟按待定档位报价。先判断能否承接，再计费；收费不能购买一个已经关闭的确认窗口。

点击、开始请求、付款回跳均不证明接受。实现须在同一受保护裁决中取得权威时间、判断截止并提交状态、版本、同意证据与Outbox；不能把事务开始前的旧时间当成功凭证。响应在16:00后返回不推翻截止前已成立的接受，回源查原结果。

## 3. 配置不是改历史

Demand拥有确认/服务时间政策；授权运营岗位通过受控命令发布新版本，记录适用服务范围、生效日期、时区、截止时间、准备时间及变更审计。具体营业时间是配置，不必以人工排班调查作为本机制定案前置。

架构采用稳定快照：订单及安排建立时固定适用截止版本和时刻，新政策用于其生效范围内新建立的安排，不静默缩短/延长旧pending的权利，也不使旧expired复活。已accepted的安排按原承诺履行。若须影响既有安排，另走有通知、授权和处置记录的变更流程，不靠直接改配置完成。

没有有效配置或没有合法时段，拒绝新增承诺；保留已承担义务的查询、停止和退款恢复。配置不能绕过终态、实际准备能力或顾客同意。配置权限与发布校验的精确合同仍需实现阶段验证。

## 4. 订单、确认与配送组合

为避免只确认一餐却放行整单，独立确认范围与可独立取消的商业范围保持一致：同单明细共用同次配送确认；需要不同独立时段的购买范围应拆单，不能让一单同时有“部分待确认、部分已确认”的整单关单冲突。这是CP-01的架构约束；部分商品售后另按D-02/03设计，不通过整单超时处理。

每个订单在同一时刻只有一个有效的鲜配确认范围，覆盖本次全部待履约行数量；改址改时或换菜建立受控后继安排并使旧范围失效，不能并存两份有效执行权。多个订单可在同日、同地址、兼容时段组合配送，但每单分别保留授权与取消结果；后加订单不能继承其他订单的确认。

一次提交可以明确确认多天、多单；用户同意应列明各自内容、地址、日期、时段及费用。每个安排独立CAS、独立回执，部分接受不得显示全部成功；响应丢失只查询原操作，不能重做已成功项。

## 5. 到期取消与状态协作

1. Demand对pending且已到截止的安排条件提交expired，同时写确认超时原因和Outbox；accepted没有expire出边。
2. Fulfillment禁止该范围开工，持久记录停止依据/墓碑，拒绝迟到授权或任务事件；不能仅凭暂时没有任务认定永远不会出现任务。
3. Commerce核验安排到期与不可执行证据，将对应open订单通过cancel迁移到cancelled，原因为 `delivery_time_confirmation_timeout`。该原因是候选语义标识，不是已发布API枚举。
4. 自动调度恢复未完成的停止、取消与资金义务。允许短暂“本次不配送·取消处理中”，不在回执尚未核实时宣称所有领域已完成；不依赖顾客登录、通知送达或人工点取消。
5. 终态旧订单和安排不能补确认复活。重新购买使用新身份，并重新检查日期、窗口、资金和同意。

order.expired保留给其他明确的商业受理过期语义，不再与本路径二选一：**已付款订单未确认配送时间的路径固定为instruction.expired → order.cancelled。** 没有新增“未正常履约”订单状态；它是由原因和实际结果组成的服务说明。

确认与到期的线性化点在Demand同一安排revision。调度晚跑不延长窗口：16:00后的confirm即使看到pending也因时间门禁被拒绝；补扫完成后取消。已在截止前accepted，即使事件晚到或当天未登录，也不能被补扫取消。

## 6. 仍未决定的资金问题

本轮没有决定即时原路退款还是暂留/账户余额。此前“暂留计划、范围结束统一退”的方向已经重新开放讨论；最新建议是确定可退后自动原路退、不默认建余额账户，但用户尚未批准。**两者都不是当前可执行资金政策。** 禁止用取消时间直接推出退款时间、留存权利或自动消费。

实际重量计价已确认，但超重收费、称重结果锁定时点、优惠/配送费分摊、舍入仍见[定案条件](../DECISIONS.md)。资金未知不得释放额度再次退款或抵扣；取消事实不等待退款完成，退款完成也不能反向复活订单。

## 7. 必须覆盖的反例

支付后立即确认未来日期；前晚确认明日；已确认者当天未登录；15:59:59.999、16:00:00、16:00之后；点击在前但裁决在后；接受在前响应在后；调度停机补扫；多天部分确认；同日多单独立取消；早时段已经不可选；截止后迟到付款；新政策不改旧截止；超时订单终态不能复活；退款未决不阻止记录取消但不写已退款。

验证入口见[状态说明](../state/FRESH-DELIVERY.md)。模型级检查不证明真实数据库时间、跨域或设备并发已经安全。