确认窗口与自动取消：机制落地复查
历史证据：保留下文编写当时的范围、发现和检查计数，不作为现行政策或未决台账。当前业务机制见确认政策，剩余事项见DECISIONS，来源分工见事实源索引。后续确认已部分收敛拆单、取消、计价与时间规则，不回写旧结果伪造当时已验证。
2026-09-29；主会话自审；仅架构文档及模型探针，不是产品实现、独立评审或S7清洁轮。
1. 本轮决定与适用范围
用户已确认订单不跨配送日/地址拆分、未切配可申请取消/换菜、按实际重量计价、后台可配置确认截止、默认配送当日北京时间16:00超时自动取消，并允许付款后立即确认未来各次配送。活动主讲：确认政策。
同步修改业务意图、总设计、流程、Demand/Commerce职责、归属表、模型、一致性和状态说明；机器迁移仍为原六类41条，新增政策元数据及guard语义，没有另建隐藏迁移。未修改原型、生产代码、Runtime或锁定REQ；没有提交推送、部署或真实资金动作。
2. 复查发现及处理
| 问题 | 已处理 | 保留边界 |
|---|---|---|
| 原文要求每天主动确认明天，阻碍付款后顺手确认 | 改为每次配送独立授权，可提前多天确认，无需每日重确认 | 已确认后无操作继续配送，取消须主动申请 |
| “不登录就不送”被错误泛化到已确认订单 | 16:00仅处理pending，accepted无expire出边 | 请求取消不等于停止成功 |
| 截止相等及有效时刻仍写待定 | 北京时间、默认16:00，t<截止接受、t>=截止到期 | 数据库权威时间原子裁决仍须实际实现验证 |
| 调度未执行可能变相延长窗口 | 即使pending，截止后confirm也被时间门禁拒绝，调度补扫恢复 | 用户点击时间不作为成功依据 |
| 安排expired与订单expired/cancelled混读 | 未确认超时固定走instruction.expired后order.cancelled，保留原因 | 实际停止及关单尚未完成时显示处理中，不伪造完成 |
| “未正常履约”可能被当商家违约或另一订单状态 | 作为服务说明，附确认超时原因；不是新持久订单状态 | 退款状态单独展示 |
| 同日多单合并后可能继承授权或整组误取消 | 商业身份、确认和取消逐单独立；独立时段拆开商业范围 | 部分商品取消/售后细则仍待定 |
| 配置改版可能缩短旧权利、复活到期单 | 固定安排截止版本；新版本不静默改已有安排，已有承诺独立处置 | 配置权限/生效验证尚需正式合同与实现 |
| 旧资金段落继续推荐暂留统一退，掩盖重新讨论 | D-05重新待决，自动原路退也只记建议 | 未批准钱包、退款时点、超重收费或自动消费 |
3. 验证
执行：
node docs/architecture/state/verify-fresh-delivery.mjs
node docs/architecture/state/verify-confirmation-policy.mjs
git diff --check
结果：原结构检查6类机器、41条迁移、280个拒绝探针、54个有序竞争探针、3个损坏定义拒绝；新增确认模型33项检查通过；diff空白检查通过。新检查读取同源JSON，不建立第二份状态表。
相对链接检查覆盖架构非模板Markdown及本报告、需求范围草稿共52个文件；本次检查目标无缺失。仅验证文件存在，不声称已检查所有章节锚点或图形渲染。
新增反例包括付款后立即确认、前晚确认、截止前1毫秒/整点/之后、已确认当天未登录、延迟响应、旧revision、补扫、重复请求、不可用早时段、跨日部分确认、不同政策快照、UTC等价时刻、迟到支付不能复活，以及超时使用cancel而非order.expire。
这些是内存布尔门禁与时间样例，不能证明数据库锁/时钟、真实鉴权、跨域停止、退款渠道或物理设备已安全。已确认业务规则不等于生产验证通过。历史审查报告保留当时结论，本报告和更新后的DECISIONS说明本轮收敛结果。
4. 仍需完成的条件
D-01至D-04已部分收敛，不再将确认开放时间、16:00边界、是否跨日拆单、基础取消阶段及实际重量计价重新列为待选。费用档位、时段计费基准、部分商品处置、超重/舍入/优惠分摊尚缺；D-05资金方式继续讨论。其他长期人员、恢复时限、Provider和现场合同保持原未决状态。
文档维护由主会话负责，业务选择由项目用户决定；本次没有凭角色名称虚构实际值班人。下一步只需围绕真正剩余的政策和合同继续收敛，不必要求用户再次确定具体员工下班时间才能完成可配置机制。