PC-03：明日配送的确认窗口
历史稿，已被当前方案替代。用户明确配送资格不需要抢，临近配送通过分档配送费承接；下文竞争名额、常规截止关单为先前未批准假设，不再作为当前建议。
日期：2026-09-23。状态：working-draft，第一轮讨论材料，以下建议与验收候选均未冻结。 上游：能力与故事台账、WCP-03至06。
1. 先界定确认是什么
用户确认的不是“我看过计划”，而是授权指定日期、指定食材范围、指定收货地址及时段的这一次配送。对应一餐还是同日多餐，应明确展示；当前一天一批只是演示简化，不作为最终限制。
付款不等于本次配送授权；常用时段可预选，但必须由用户提交。未确认不送已明确；具体开放/截止时刻、时区、满额和临时加单规则尚待决定。
候选时间模型：O为本次确认开放时刻，C为截止时刻。尚不填写具体钟点；建议采用服务区域统一时区、服务端权威时间，区间是否包含截止瞬间需在合同中定义，不由手机时间裁决。
2. 用户故事与可观察结果（提案）
| ID | 场景与用户愿望 | 体验应回答什么 / 候选验收 |
|---|---|---|
| CW-01 | 周末付完一周安排，我想放心离开 | 展示已付范围及首次可确认日期/窗口；没有让人误以为每天已承诺送达的勾选 |
| CW-02 | 尚未到窗口，我提前回来看看 | 看清已付安排和开放时间；不要求现在操作、不伪造可点击确认 |
| CW-03 | 明天在家，我想很快定好送达时间 | 进入对应日期/批次，核对食材与地址，选择有效时段，一次提交；不重复付款 |
| CW-04 | 今天很忙，完全没打开小程序 | 到截止无有效确认则不配送；不需要我取消，其他日期不被清空 |
| CW-05 | 点击确认后网络断了，我不知道成功没有 | 保留选择，先核验同一次提交；未知不是失败，不能给出虚假的已确认，也不重复创建配送 |
| CW-06 | 常用时段满了，我仍想收到这一餐 | 明确不可用时段及可用替代；不擅自换时间；全部满额时另列服务不可用，不归咎用户未确认 |
| CW-07 | 我晚了一点回来 | 明确本次是否已截止、是否不送及资金当前事实；不因打开页面自动恢复、不自动挪到次日 |
| CW-08 | 我拒绝提醒，或通知没有送达 | 页内仍能完成确认；不强制授权，不以未读为同意，也不承诺通知必达 |
| CW-09 | 我和家人同时操作，或反复点击 | 只产生一次有效结果，后来者看到最新状态；家人代理权限另定，不因同地址自动授权 |
| CW-10 | 旧提醒把我带到已经处理过的一天 | 读取当前事实，不执行提醒中的旧状态；已确认看时间，已截止看结果，不能复活旧按钮 |
3. 四条主要动线
A. 正常确认：回来不必重做决定
进入计划/我的入口，或经授权提醒直达 → 验证登录与该记录访问权限 → 定位本次日期与批次 → 显示已付食材、地址和可用时间 → 用户明确提交 → 权威结果返回 → 原地显示已确认的日期/时段/地址 → 可退出。
建议正常分支只突出一个主要动作。无需再次选菜、填人数或付款；不强行增加成功弹窗和促销。登录过期应保留目标地址，恢复身份后重新核验，不直接执行确认。
B. 不操作：系统收尾，不追责用户
窗口开放 → 用户没有进入或没有提交 → 截止判定无有效确认 → 本次不配送 → 独立记录资金处理 → 用户下次进入时看到结果与后续入口。
停送与资金留存是两件事。资金处理尚未完成时只显示待处理，不抢先写“已留存”。不得自动改成下次配送，不把跳过写成“失约”。
C. 点了，但结果不确定
提交 → 断网/响应超时 → 显示正在核验或结果待核实 → 再次进入/重试先查询原请求 → 已接受则展示同一确认；明确未接受且窗口仍开放才可再次提交；已截止则按权威判定处理。
截止与提交并发只能落一个最终结论。请求抵达、被接受和设备点击时间的判定口径仍需技术合同明确；用户不应承担推断责任。旧请求在确认后变更规则中的版本处理依赖PC-04。
D. 没有合适的时段
核对食材 → 常用时段不可用 → 用户选择其他可用时间 / 暂不确认。若全部时段不可用 → 说明服务能力受限 → 明确本次履约与金额后续，提供可追踪处理入口（能力待建设）。
不能用“未确认”遮蔽商家供给失败，也不能以一句“联系客服”假装闭环。是否候补或补送、承诺多久响应，均待运营能力与政策支持。
4. 我建议的方向与取舍
| 问题 | 候选方案 | 建议与代价 |
|---|---|---|
| 确认周期 | 前一日开放；或允许提前多日确认 | 先按前一日窗口设计，贴近已明确机制；更灵活的多日确认另议，不能悄悄引入自动配送 |
| 截止呈现 | 持续倒计时；或静态明确时刻 | 建议静态日期/时刻，必要时轻提示；减少压力，但用户仍需要清楚可见的时间信息 |
| 截止后 | 常规关单；或允许运营评估的临时加单 | 建议常规关单为基础，临时加单作为独立请求且不承诺成功；避免原确认被无条件复活。此建议待用户确认 |
| 提醒 | 高频追催；或自愿、有限提醒 | 倾向有限提醒，具体次数与渠道交给PC-02；提醒失败不能改变默认停送 |
| 已付与运力 | 支付即预留粗粒度运力；或确认时再竞争容量 | 暂不选定。后者容易导致已付却完全无时段，前者增加库存/运力成本；必须由运营与用户共同确认服务承诺 |
5. 第一轮需要回答的三个问题
- 时间边界：是否坚持前一日逐次确认？实际采购、切配和排车最晚需要何时拿到数量？先说明这些约束，再决定O/C；旧20:00不是已批准答案。
- 迟到余地：截止后常规不再恢复，是否仍允许用户发起独立的临时配送请求？没有履约能力时不展示“保证补送”。
- 付过钱的保障：周付款是否意味着届时至少有可选配送时段，还是仍需确认时争取名额？若不能保证，需要在付款前说明并设计服务补救。
回答登记：以上三项均PENDING。页面结构可使用“开放时间/截止时间”占位讨论，不能把占位示例当运营规则。冻结时间前还必须明确时区、边界瞬间与节假日变化。
6. 反证、责任与下一步
以下任一现象将否定“无忧确认已完整”：无确认也发货；通知失败导致自动授权；跨设备重复配送；全时段满额却责备用户；客户端改时间绕过截止；越权读到他人地址；资金未处理却写完成；一日停送改变其他日；已付后数据变化仍确认旧价格/新食材混合快照。
当前模型仅本地模拟日期与时段，不具备上述服务端、支付、权限或并发保证。后续验证需包括正常、无操作、零可用时段、截止竞争、重复提交、跨设备、过期通知、身份失效、数据异常与恢复。用户体验测试还需验证能否不经解释说清“付没付、送不送、什么时候送、我现在要做什么”。这不是已执行的验收。
设计主会话维护本稿；用户确认业务取舍；运营负责提供备货/运力事实，具体负责人未指定，仍是实施前阻碍。技术实现人员及财务责任人未指定，不能以域名称替代责任人。下一轮先记录上述选择，再展开PC-05；不同时索要全部政策。
本轮不改UI或模型，无迁移/回滚操作。后续若改变已批准规则，须记录新旧决策、受影响故事与恢复方案；不能覆盖原始记录后声称从来一致。