付款后的陪伴：能力、用户故事与讨论台账

日期：2026-09-23。状态：working-draft，用户授权记录式梳理，未批准以下候选规则。不是locked REQ、实现合同或上线能力清单。

业务依据：一周无忧计划；已有布局提案：周计划体验。本文件只管周计划售后续程，不默认为独立选肉订单修改规则。

1. 记录约定

已明确：先规划、一次付款、逐日主动确认；没有确认就不送，不要求用户进入应用取消；不影响其他日期。
暂定：未履约金额留在计划中；不推出自动抵扣、结转、过期或充值。
新增明确：无需抢配送资格，商家尽力承接；按用户期望送达时刻计算，提前满两小时（含相等）确认免配送费，不足两小时逐级计费。档位与交易细则待定。
建议：设计主会话提出的候选行为，未获用户确认。
待决：必须明确后才能冻结合同；不允许用旧演示值填空。
原型已有：只代表本地模拟，不能写成真实支付、通知或履约能力。

设计目标：用户离开时知道已完成什么、何时需要再行动、不行动会怎样；回来时无需重新解释自己的安排。

原型推进记录

用户随后授权先以预填机制补原型，不为参数逐项等待确认。Study29已补PC-01付款回执、PC-03明确时刻/费用/确认结果及当天重新安排，PC-08仅增加本地逐次配送费记录。下表保留首次盘点背景；这些进展仍非真实服务，也未解决站外提醒、正式收费、资金退出或账本统一。预填档位不加入已批准业务规则。

2. 能力与故事总览

能力/故事	作为用户，我希望……以便……	当前证据与缺口	讨论依赖
PC-01 付款交代	付完后看清已付安排和下一次动作，放心离开	`payment()`仅关闭弹窗并选择日期；缺完整结果摘要，真实支付结果未知未接入	PC-03/05
PC-02 提醒与直达	在合适时间得到可选择的提醒，直接确认对应配送，不再找订单	页内入口已有；站外渠道、授权、频率、退订、失败路径未定	PC-03、渠道可行性
PC-03 确认与配送费	按偏好选时间，提前看清配送费，不抢资格	只确认模拟明天、费用0元；缺临近确认与分档费用	计时、档位、调度与收费交易
PC-04 修改与撤回	确认后临时有事时知道还能改什么，不必猜测代价	新周计划缺改地址、改时段与撤回闭环	PC-03、备货/发货边界、PC-05
PC-05 留存与退出	查清没送那次的钱，并知道如何再用或退出	有金额展示；重用、结转、退回、费用分摊待决	财务与业务政策
PC-06 已付安排变更	换菜或改份量时只处理受影响部分，不重付整周	有快照、不一致拦截与恢复；缺补退差价/缺货替换闭环	PC-04/05、库存与价格
PC-07 履约与补救	确认后知道进展，异常时有人接住，不重新描述整件事	配送/送达手动模拟；新计划尚无完整异常与售后链	真实库存、作业、配送与服务责任人
PC-08 一致记录	换入口或设备仍看到同一事实，不重复付款或确认	周计划本地账与旧订单隔离；旧自动配送/退款规则冲突；真实核验、同步未接入	所有状态、资金与模式边界

依据：实验目录study-week.tsx的payment/confirm/records，study-week-model.mjs的payWeek/confirmDay/advanceDay/totals，以及study-mine.tsx；整体回看。文档尚未定义即记待决，不假设后台已经实现。

3. 全程动线：先有骨架，再逐项细化

核对一周 → 发起支付
  ├─ 结果未知 → 核验支付结果（不能要求再次付整周）
  ├─ 已知失败 → 保留安排 → 用户决定重试
  └─ 支付成功 → 已付安排摘要 + 下一次行动 → 可以离开
       ├─ 未到窗口 → 查看安排，不假装已确认配送
       └─ 窗口开放 → 自主进入 / 自愿提醒直达
            ├─ 查看对应批次 → 选择时间 → 展示费用 → 明确同意并处理费用 → 确认结果
            │    ├─ 结果未知 → 核验 → 已确认 / 可重试 / 已截止
            │    └─ 已确认 → 日期、时间、地址 → 备货与实际配送
            │          ├─ 正常送达 → 留下可查记录
            │          └─ 异常 → 说明影响 + 可追踪处理
            └─ 到截止仍未确认 → 不配送 → 资金处理事实另记
                 → 再次回来：看清这次结果，其他安排继续

这不是按页面硬拆的流程。计划承载安排，付款结果承载完成感，确认面承载本次授权，明细承载依据；不要求每个节点新建一页。未确认停送是正常支路，不是失败惩罚。

纠偏：图中截止是尚待定义的履约关闭条件，不是提前两小时。临近配送走费用路径而非默认拒绝；支付与接受的先后及失败补偿待合同明确。

4. 分轮讨论与交付

顺序	议题	本轮状态	收敛后留下什么
1	PC-03 确认与配送费	用户补充，见故事与动线	两小时基准、档位、费用授权与临近承接
2	PC-05 钱的去向	待展开	金额归属、重用、退出与处理失败的故事
3	PC-04/06 改变主意	待展开	可改范围、费用、再次授权与恢复路径
4	PC-01/02 付款交代与提醒	待展开	成功/未知/失败、提醒授权及直达动线
5	PC-07/08 履约与统一记录	待展开；一致性约束从第一轮就保留	履约异常、服务跟进、记录与核验边界

每轮记录：用户故事→正常/异常/不操作动线→设计建议与替代方案→用户结论→受影响文档/原型→验证证据。没有答复的项目保持待决；不因为下一轮开始就默认为同意。

5. 决策与责任

决策	当前状态	后续
DEC-PC-01 付款后仍需持续服务，但不增加打扰	用户认可的设计方向	用事实与恢复路径体现，不增加情绪口号
DEC-PC-02 用故事与动线逐项记录	用户本轮授权	从PC-03开始，保持关联ID
DEC-PC-03 确认具体时刻及迟到规则	待决	不继承旧Demo的20:00
DEC-PC-04 留存资金再次使用与退出	待决	“暂留计划”不等于可无限期扣留
DEC-PC-05 配送资格不抢，按偏好定时间	用户本轮明确	撤回竞争名额假设，尽力承接不冒充无限必达
DEC-PC-06 提前满两小时免费、不足两小时逐级计费	原则明确，细则待决	档位与费用授权待定；原型未实现
DEC-PC-07 计时基准与相等边界	用户确认：按期望送达时刻，恰好两小时免费	18:00期望送达、16:00确认免费；有效确认技术时刻及时间段UI适配待定

设计主会话维护记录与证据；用户确认业务选择。运营、财务、支付、履约实施责任人尚未指定，属于实施前未完成项。技术边界不能由一个页面看起来顺畅代替验证。

本轮只写设计工作稿，不修改原型、Runtime、旧快照stories/flows或正式资金合同。若后续发现规则冲突，保留历史决策，记录替代关系再同步相关模块；不直接迁移或合并本地演示账。