BC-05｜预约承诺与订阅（demand）

状态：working-draft；本次边界建议，未批准为完整新基线。
Design=draft；Contract=not-defined-here；Implementation=not-assessed；Verification=document-review-only。
上游：SD-03（仍为候选占位）
输入：既有模块设计（历史材料保留在 docs_bak/）
编写责任：主会话；业务决策 / 长期维护责任人：待指定。日期：2026-09-18。

1. 需要什么，它是什么

决定什么需求能够被接受，以及如何维护预约和周期性服务承诺。

统一语言：Availability 是基于输入的时点判断；Hold 是临时占用；Commitment 是已接受承诺；SubscriptionContract 是持续关系；Cycle 是一次周期意图。

2026-09-29：一周无忧不默认建立 SubscriptionContract。个人餐次归 Customer，购买批次与订单归 Commerce；Demand 新增本次配送安排与不可变明确确认记录，维护每次配送确认/到期裁决；付款后可提前确认未来多天，无需每日重复。默认配送日北京时间16:00未确认自动取消，后台配置版本不静默改旧安排，见确认政策。订阅只是独立待定能力，不得绕过用户逐日授权。见交易级严谨性。

2. 拥有与不拥有

拥有： 时段、容量资源及输入、占用与承诺账本、每日配送安排/确认/到期、预约改期及冲突；另有待定的订阅合同周期和权益，不与周计划混同。

不拥有： 实体物料、成交价格、标准订单、支付、实际作业；履约能力输入的原始事实归 Fulfillment。

这里列出事实族和职责，不直接定义数据库表、聚合事务范围或最终接口名称；详细模型须在下一层继续验证。

3. 谁参与，怎样使用

顾客查询时段、管理订阅；运营配置承诺政策及处理冲突；Commerce 申请和确认占用；Worker 生成周期；供给和履约提供能力输入。

典型场景：查询可承诺 → 结算流程申请 Hold → 确认订单流程提交 Commitment；订阅锁定周期 → 请求 Commerce 创建标准订单。暂停订阅仅作用于政策允许的未来周期。

4. 如何与其他上下文协作

引用 Identity 服务区域、Customer 资格/地址和 Catalog 规格；接收 Supply 与 Fulfillment 能力输入；向 Commerce 输出承诺结果和周期意图。

调用方向、信息方向、流程协调者和失败责任统一见 CONTEXT-MAP；事实边界及混淆项见 OWNERSHIP。不使用共享可变实体或跨 Owner 写表。

5. 不变量、权限与一致性

能力输入不足或过期不编造容量；确认与释放幂等；已承诺需求不能随能力下降被静默删除；订阅不建第二套订单。

所有入口遵循 统一授权接缝。本上下文负责自己的资源关系和业务动作条件，不能仅凭客户端提交的角色或对象归属放行。

6. 失败、并发与恢复

容量守卫在本地一致性边界内裁决，不向用户承诺“抢配送资格”；Hold 过期与确认、每日授权与到期分别裁决。改期未影响旧义务即拒绝时保留原承诺；冻结后按停止协议推进，不静默恢复，更不复活终态。周期订单未知查原意图；已终止后新的明确购买使用新意图。撤销每日授权须取得 Fulfillment 停止/处置回执，不能仅发异步事件就宣称停止。

部署和数据库共用不构成跨上下文原子性承诺。需要立即成立的约束在对应事实 Owner 内执行；跨域步骤记录意图、版本、结果与恢复进度。

7. 边界取舍与可能推翻结论的证据

保留一个候选 Demand 上下文，但预约与订阅分成内部责任区。长期合同与短时容量语言不同；若权益独立计费/转让/多履约模式成立，应拆 Subscription，经显式契约使用 Capacity。

反证检查：验证同一初始出单意图不重复建单、后继单谱系可追溯、暂停不回写已履约周期、容量下降不删除承诺、改期不出现新旧双占、到期旧安排无法重新确认。不能把当前组合当作最终边界结论。

上述是设计反例清单，尚未执行产品测试。拆合讨论及重开条件见 BOUNDARY-DECISIONS。

8. 未决事项与后续交付

预约与订阅是否拆分、权益商业规则、容量政策、改期协议、失效时限与责任人待明确。

先核对本页业务范围及上下文边界，再细化模型、不变量、状态、命令/查询/事件和授权契约；最后派生完整业务增量 REQ。不得据本稿直接锁定开发接口。当前未决项统一归入DECISIONS对应D项；REVIEW仅保留历史审查及Q项来源，不另作活动决策台账。