# Study29：付款后，留下一份安心的安排

状态：experiment。用户授权以预填机制推进原型，不等待正式运营参数。不是资金合同或正式能力上线；首选来源快照不变。

## 本轮完成的体验切片

1. 周付款成功：完整安排回执，列本次日期、菜品、天数及食材金额。可直接选择明日送达时间，也可回计划或查明细；不强迫确认，不追加推荐购物。
2. 明确时间与费用：以12:00/16:00/17:00/18:00/19:00作为期望送达时刻选项，替代本路径含混的时间段；显示地址、费用，已付食材可展开核对。
3. 确认后的收尾：显示日期、期望时刻、地址、本次配送费。回到计划后结果仍可查，不要求重复确认。
4. 当天重新安排：模拟进入下一天后，未送食材仍保留；当天提供重新安排入口，不重付食材。只在明确同意费用后恢复本次履约，其他日期不改变。
5. 恢复：网络失败与配送费支付失败保留选择；重复确认和过期费用拒绝；费用记录刷新后仍在。

边界：本次没有实现站外提醒、真实支付结果核验、真实配送、已确认后改时/撤回、资金退出、缺货补救或旧订单账统一。不能把六条局部验证结论当作八项缺失能力已全部补齐。

## 预填机制（可换，不是业务批准）

- 用户已确认：期望送达时刻减确认时刻≥120分钟，配送费0元；不抢配送资格。
- 原型预填：60–119分钟¥3，30–59分钟¥6，1–29分钟¥9；已过时间不可选。一天一批，当天/前一天可确认。
- 模拟时间手动推进，默认12:00；进入下一天恢复12:00。费用在本地提交时重新核算，不匹配则拒绝，不静默升级。
- 配送费独立存于该次记录，不从食材留存款自动扣。食材金额汇总明确标为食材已付，配送费逐次列出。
- 当天重新安排由skipped转为delivering；前一天确认为confirmed。是演示简化，不是真实履约事件。
- 模拟费用支付与确认本地一次写入；不能证明真实支付与履约的原子性、并发、跨设备一致性。

预填说明和模拟时间控制位于`/phone`手机框外。原型内部保留模拟支付措辞，避免被理解为真实付款。

## 体验路线

正常：计划 → 核对本周安排 → 模拟支付 → 安排回执 → 选择明日送达时间 → 确认 → 确认结果 → 回计划/配送明细。

临近：新演示记录先周付款但不确认 → 回计划 → 框外展开“原型体验”，进入下一天 → 模拟时间17:15 → 对应当天“安排今天配送” → 选18:00 → 配送费¥6 → 模拟支付并确认。可先切换支付失败/网络异常，再恢复正常；同一份食材不会重付。重置只用于隔离演示，应先确认不需要保留本地记录。

## 设计与证据

结果页使用纸面回执、轻量完成标志与安静的去向，不复制我的页深色身份层。初始回执过长，截图检查后收紧标题、日期行及段间距；没有裁切或禁止滚动。小屏、长菜单允许滚动，未承诺所有信息一屏。

`verify-care-flow.mjs`通过：费用边界（含恰好两小时）、过期时间/报价、快照/重复拒绝；周付款回执；免费确认与费用记录；当天恢复及支付/网络失败；刷新保持费用且无重复食材扣款；320px明细无横向溢出。`care-29-proof/`含结果、手机截图。已查看付款、免费/收费选时、确认结果截图。

菜卡七组回归、我的七组回归通过（测试补上新回执的返回动作，不删除原断言）；周模型与菜卡模型验证通过。固定来源35c0d16的93文件未变，构建与`git diff --check`通过。首次脚本失败来自金额格式预期（¥0而非¥0.00）与回执返回后外部details重新折叠，修正测试操作后重跑通过。

尚未验证真机微信、系统大字、完整读屏/对比度、所有旧路由、真实资金/运力；没有独立评审。旧`verify-week.mjs`时间段断言已过时，不能作为本轮结果。自动化不证明情绪目标已达成，仍需用户体验。

## 维护与恢复

实现：`study-care-result.tsx`、`study-care-flow.mjs`、`study-week.tsx`、`study-week.css`与周模型可选模拟时间。新记录增加可选deliveryFee/confirmedMinute，旧记录可读；旧confirmDay保留供历史模型调用。回退前需保留新增费用记录，不能删除收费事实或把新精确时刻当作旧时段直接重放。

设计主会话维护。仅实验目录变更，未提交、发布、绑定REQ或冻结Foundation。后续优先按用户体验细化回执和确认，再独立补提醒及服务补救，不越权确定真实价格。